BODM / class diagram questions

[Jim Janssens]

When you start from a conceptual model (BODM) you already identified several parts ("nouns") of the system.
For an online shop you might with the following classes in your BODM: "customer [1] ---- has---- [0..*] LineItems".
After that, you can continue to add more system related elements to your BODM so it will form the high level class diagram.

One of those "things" I add are classes containing logic to "do" something with the classes from the conceptual model.
Some of these classes having logic will be responsable for storage.

I add entity bean classes to manage storage, Session bean facades for interaction with the clients and possibly some internal 'processor' classes dealing with business logic. My class diagram then might looks like this:

Scenario1:

[client]----invokes----[facade]-----uses----[BusinessObject: Customer entity bean]------persists using-----[customer DAO]
  |                                                  |                                                         |
  |                                                  |                                           -----dep------|
  |                                                  |                                           |
  |                                                  ------------------dep------------------[Customer]--has--[LineItems]
  |                                                                                              |
  |---------------------------------dep----------------------------------------------------------|

As you see the customer is the original class from the BODM. In this case it contains no logic at all, it is a plain java bean only having get/setters and a internal collection to administer the relation with LineItem. In fact by doing this, I automatically treat my BODM class Customer as a Transfer Object. Both client, entity bean and DAO have a dependency with Customer, as they will send it forward an backward.

The customer entity bean will be a composite entity. For me this means that it will have more then one DAO to store the complex object Customer. For example:

[Business OBject: customer entity bean]--------persists customer using-------[customer DAO]
           |
           |---------------------------------persists LineItems using--------[LineItem DAO]

I feel that there is a problem with this approach. I think that customer class and the LineItem class should be the BusinessObject itself. Thus I will create business objects from the original classes comming from the BODM rather then creating additional ones.

In order to do this, I must create a business object for LineItem as well, otherwise I cannot indicate the relation of these two classes. The diagram then looks like this:

Scenario2:

[Business OBject: customer entity bean]-1-------has-----0..*-[Business OBject: lineitem entity bean]
           |                                                            |
           | persists using                                             | persists using
           |                                                            |
      [Customer DAO]                                                 [LineItemDAO]

This way I still keep the composite view, since my facade session bean will use the customer entity bean (which has a getter to get the customerTO's wich has a getter for LineItemTO's loaded by the LineItem entity bean).


My questions:

a) is scenario 1 a valid solution ? Is it right to treat BODM classes like TO's in the class diagram ?
b) is it valid to use composite entity like in scenario 1 ? Having one entity bean as the "composite view" with several DAO's and no more real entity beans as ?
c) Should I go with scenario 1 or 2 ? or are there other (better) scenario's ?

Thanks.

[Ilja Preuss]

I'm not sure I understand your approach to design, and therefore your questions - but your approach 1 sounds like it might have something in common with what Martin Fowler calls an Anemic Domain Model: http://www.martinfowler.com/bliki/AnemicDomainModel.html

[Jim Janssens]

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.

[Sudd Ghosh]

"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"

The find method will live in the Home interface of your Customer entity bean. It'll be looked up by the client appl using a reference to the home interface, which it gets using a JNDI context lookup.

[Jim Janssens]

Originally posted by Sudd Ghosh:
"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"

The find method will live in the Home interface of your Customer entity bean. It'll be looked up by the client appl using a reference to the home interface, which it gets using a JNDI context lookup.

Yes, but in my question I'm refering to the scenario where I use a DAO instead of entity beans. For the DAO scenario I could also create a static method on Customer class to find Customers. This method would then access the DAO behind the scenes.

With entity beans thats indeed no problem. I know you can use the finder methods of the home interface. I am however not exposing my entity beans to clients. My entity beans will only be exposed to my domain model and/or session facades.

Is there any chance someone can answer my questions ?

[Jim Janssens]

Originally posted by Koen Serneels:


Yes, but in my question I'm refering to the scenario where I use a DAO instead of entity beans. For the DAO scenario I could also create a static method on Customer class to find Customers. This method would then access the DAO behind the scenes.

With entity beans thats indeed no problem. I know you can use the finder methods of the home interface. I am however not exposing my entity beans to clients. My entity beans will only be exposed to my domain model and/or session facades.

Is there any chance someone can answer my questions ?