Exactly !!
That is what I'm doing wrong, I'm actually creating an 'Anemic domain model'. To be honest, I had a feeling that my design is going towards to an anti-pattern (did not know it had a name until you posted that link).
I also understand the alternative: a domain model. and I agree on the part that data should be combined with the actual business logic (which I'm not doing in my anemic domain model).
For example:
If I would want to calculate the total price of the products currently assigned to a customer, I would put this code in the domain object "Customer". I would ask the Customer class to calculate the total amount. The Customer class will then use internal data to identify if any discount is aplicable. Next it will iterate over the internal collection of Item objects and ask each Item object for its price. Together with the total price and the rules for applying the discount, the Customer class will return the total amount.
The (ant-pattern) alternative (the way I'm working now) would be creating a class "OrderCalculator" which takes a Customer to calculate the total amount, and thus only treating Customer as data. The business rules would now be in OrderCalculator, and OrderCalculator would only use Customer for getting its data: getDiscount(), getItems() etc
----
If this understanding is correct, I have several questions regarding to the domain model approach:
1. How are you going to *store* the data in Customer ? Will Customer be responsable for going to the database directly ? Or will you create a CustomerDAO that takes a Customer for persistence ? The book I'm using "
Patterns of Enterprise Application Architecture" specificly avoids the answer to this question.
Personally I would use a DAO for storing and loading Customers. I do not see how to have a "findCustomer" method on the Customer class itself. Its more logical the ask the DAO to find customers. The DAO will then return a Customer class. Using hibernate, the Customer class will then be configured in the mapping file as data class: it will have get/setters for each attribute (so hibernate can load and save data) AND the business logic. Is this a valid approach ?
2. Assuming that a client needs Customer information, I think it would be logical to add additional get/setters to Customer for retrieving and setting a CustomerTO (TransferObject) ? I do not want to send an object containing business logic to a client..
3. Working with POJO's and DAO's is nice. But how can you port this to a
J2EE system required of using session and entity beans ?
I understand the patterns as 'application service' in combination with 'service facade'. I will only use the session bean to orchestrate some actions using my domain model. I will keep as much logic in the domain model and out the session beans.
But what about the entity beans ? Should I make Customer an entity bean ? Since a domain model requires (more or less) that data is together with business logic, I see no other way. This way my entity bean would be a valid domain object since it contains business logic and data AND it would be able to persist/load itself to database.
Basicly , this approach comes down on having all my domain related business logic inside entity beans. I have some difficulties accepting if this the real goal of entity beans...
Thanks.