if you don’t have any behavior, don’t worry.
I’ve been reading a lot of blogs lately by object-oriented people who complain about the increasing separation of code and data in the domain layer. They claim that in good object-oriented programming the behavior and the data are supposed to go together. While this is true in principle, it doesn’t necessarily mean that you should start out trying to model object in your problem domain with classes and then adding a bunch of “behavior” to them.
The truth is that most domain objects in business applications don’t really have any domain specific behavior that should be associated with them. There are multiple domain-inspecific behaviors, such as serialization, comparisons, input validation, etc… which is why I always advocate using a dynamic object model framework to implement domain objects. The most important domain specific behavior to be executed on most domain objects are: 1) Display it to the user and/or allow editing. 2) Store it in a database.
Neither of those behaviors belongs in the domain layer, because it is not about the domain, it is specific to your infrastructure. Now, if you’re building an accounting system and you have complicated domain logic, then it should be in your domain layer, but if all you are creating is a CRUD system, then just let the domain objects be, and quit whining.