In the domain layer I have the domain objects (objects which models the business data). There are certain business logic needed to apply when these objects are created.
Until recently I used to have a DomainObjectFactory which will create domain objects out of data value/transfer objects and apply whatever business required. In this way ... there was a clear separation between the data (plain domain objects with just getters & setters) and the business logic.
I would like to put in discussion a different approach .... which is to store the data and the business logic in the same place. In this case the domain objects using their constructor will be able to initialize themselves and also apply the business logic. The problem in this case the object values and the domain objects will be mixed together.
Fundamentally the paradigm is reduced to the basic questions: Should the domain object store only data ... or rather store data & logic?
I'll appreciate any input regarding this topic.
I often thought about this question in the last months and often came down to the same. If you're using EJB's then I would recommend only having data objects and no logic in them. I would have all the logic in the stateless session components.
Whenever I had logic in the value objects I had to send more data over the wire, as many BL operations also changed other value objects, that had not to be transfered in the direct context of the user, but in the context of the operation. So when having the logic in the value object those data objects where also necessary on the client.
My approach here is to keep the value objects simple: constructor(s), accessors and one business logic method "validate()" that can take an optional operationType parameter. As the name implies, this method does basic domain validation: checks for empty fields and "common sense" values (e.g. 1 <= month <= 12) and throws a ValidationException.
I ve got a similar picture in mind. Indipendent from the j2ee infrastructure where I am still a novice, my domain can only be accessed via a local facade. The local facade is wrapped by a remote facade. While the remote facade enforces a coarse grained data transfer object model the local facade enforces the fine grained local domain model.
Domain object are usally composite structures consiting of header-, line- and line component objects which are stored in different tables depending on the level within the composite (imagine an invoice or any other kind of document).
Depending on the business case at hand domain objects are validated according differing business rules although stored in the same table. That was the point where I started thinking to have different validation rules modeled as different classes while the 'domain object composite' should be more generic in nature. Every part in that domain object composite is required to extend a relational object class that specialized dao's are able to handle.
Further the abstract relational object class enforces to implement an accept(Visitor) method. This allows me to write a library of validation visitors implementing various business cases and keep them seperated from the domain obbject composite and after all configurable.
A bunch of patterns but it helps me to deal with lunatic business folks that change their requirements from time to time.