business objects and class/BODM diagram

[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.