This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
please try to find out with me how I can merge both the Business Domain Object Model and the J2EE Technology so that at the end I will obtain a full fledged Application that fullfill the domain model and the requirements.
I would like to take the case study example in Mark Cade's SCEA book (p.158) for this discussion.
First of all we get a number of use cases and a business domain object model (BDOM) as below from a business analyst:
After reviewing the case study's use cases (which I don't show here) we end up with the class diagram below:
Let us concentrate on these 2 diagrams and some more to come in this thread when we go on in our discussion.
One thing I see is that the domain model (BDOM) is something logical (which is in our brain or on paper) while the class diagram is something phyiscal which we will implement in the end.
Another thing I see is that the BDOM is free of any technology aspects while this not the case for the class diagram.
Can you live with the fact that we already changed the BDOM when we created the class diagram. Where is the relation between Order and Product :
Didn't that case study say:
Mark Cade in SCEA Study Guide p. 159:
The business analyst created the ... and business domain object model. This is an accurate representation of the system and you cannot modify or change it in any way. ...
What about that? Isn't it what we just did in our class diagram .
Now this was not my main intention for this thread. What I want to get out of this thread is how to make the bridge between domain models (BDOM) and the J2EE Technology. And to be more precise, I mean J2EE technologies like JSP, Servlets and EJB.
How to implement the business logic with above technologies? How would these look in our class diagram?
What about Persistence? How would this look like in our class diagram?
I hope this discussion is fruitful not only for me
This is an exhaustive post . Let me try to answer the questions.
1. Association between the product and order: If you check the class diagram again you can see that Order-->OrderItem--->Product relationship.
2. Changes to the BDOM: Class diagram didnot change the BDOM. It just elaborated BDOM adding more components and created more detailed view (class) using BDOM as base.
Now let me try and answer other questions.
A. How to implement the busniness logic with above technologies? How would these look in our class diagram? Answer to first part of the Question: First we need to move the detailes provided BDOM in to different TIER (Client, Presentation, Business & EIS / DB) Answer to second part of the Question: Now for each tier we have to start designing. Client Tier - Create user experiance Presentation Tier - Create class diagrams Business logic - Create class diagrams EIS / DB Tier - Create ER diagram based on the BDOM. Other than class diagrams we might want to use Activity, Sequence, Collaboration diagrams. These diagrams will be very useful during the implementation. These are optional and can be used based on the need.
B. What about Persistence? How would this look like in our class diagram? There are two aspects to persistence: 1. Class diagrams: EJB's represent datastore in terms of java object, it can also be DAO or may be POJO's that is used to access data. 2. ER diagrams: This will be useful to design the database and will be very useful to care to create DB.
I hope this is helpful and i expect other to contribute.
Joined: Aug 21, 2004
I was thinking about leaving the BDOM (problem domain = PD) untouched and provide another layer for the persistence (data management layer = DM) so that I can keep any technology aspect out of the BDOM.
See below (I think there is still something missing but see it as a first try :roll: ):
Thanks Panindra for your answer . I also hope that more people let us know what they think.
Joined: Sep 07, 2004
Your right again, if you look at your PD all of them are interfaces. So you can leave this layer untouched but the problem is that all entity beans in the DM implement interfaces from PD.
This means that interfaces in PD should atleast consider the basic skeleton , about the way you want to implement the persistence. I mean your interface should be inline with your thought process about persistence.
One more way to address your thought to "keep any technology aspect out of the BDOM" is to design the entity beans such that they use DAO. Which would really worry about the technology aspect of persistence and do away with the interfaces in the PD and instead move the entity beans up to the level of BDOM and move the DAO (classes) to the DM. If this is your choice then you have to do away with CMP beans, but if you want to use CMP then container is really going to worry about the technology aspect of persistance .