Hi,
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. The case study describes a company that has requirements very similar to Amazon.com.
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 show below w/o description per use case)
we end up with the class diagram further down:
Let us concentrate on the diagrams domain model (BDOM or better Problem Domain PD) and class diagram and some more to come in this thread when we go on in our discussion.
One thing I see is that the domain model (PD) is something logical (which is in our brain or better on paper :) ) while the class diagram is something phyiscal which we will implement in the end.
Another thing I see is that the PD is free of any technology aspects while this is not the case for the class diagram.
What I want to get out of this thread is how to make the bridge between domain models (PD) 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 ;)
Regards,
Darya
Separate DM from PD with J2EE's EntityBean EJB
Hi,
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 PD.
See below (I think there is still something missing but see it as a first try :) ):
I must admit that the domain model (PD) is not the best one can think of but it's from Sun's Study Guide for the Sun Certified Enterprise Architect (SCEA) exam which of course is propagating a solution with J2EE's EJB technology.
I don't like the class diagram which Sun provide as a valid solution because there is no clean separation between the PD and the applied technology.
We say here that the DM is not worth to model anymore because there are ready baked solutions (Hibernate, JDO, EntityBean) for it, but honestly I still find it tricky to model the DM especially when we do it with EntityBean where it's hard to stay clean.
What do you think, is the approach still good to go with?
At the end I want to replace the class diagram given by Sun with a solution that is conform with FDD (Jeff De Luca, Peter Coad) object modeling's thinking.
Let me know what you think :)
Regards,
Darya
Separate UI from PD with J2EE's SessionBean EJB (SessionFacade)
Hi,
please look at the next figure below:
I try to make further use of J2EE EJB and separate the UI from the PD through a Session Facade. The EJB container provides transaction management, security, distributed transactions and remote access. Actually thats the reason why I want to stay with J2EE EJB.
The façade here should fill the gap between UI and PD so that the workflow of the application is realized in its classes (OrderProcessor, SearchProcessor and AccountManager) and at the same time let me use all the EJB services.
Doing so encapsulate the domain model (PD) and let the PD objects free of any technology binding.
Makes that sense :?
Regards,
Darya
i want more
- The project definition
- The project scope
- The functional requirements
- The non functional requirements
and
- The sequence Diagram
- The System operations and the corresponding contracts
- The collaboration diagram
- The class diagram
Only One Model
Hi,
there's a couple of isses you've raised here, but I want to start with this one: there is only one model.
By this I mean that when we do initial domain modelling, the class diagram's that we end up with ARE the domain model. That's what we go on to build. As we iterate through the design and build by feature steps we are adding content, but the shape should stay pretty much the same. We do not "park" the domain model, and then go on to map it to something else. We simply build that model.
That's why we favour tools that allow simultaneous round-trip between the model and the code - they are just two different expressions of "the domain model".
In my experience a "business domain object model" from a BA is not only useless, it's harmful. Having (essentially) one person sitting on their own coming up with "the model" is a bad thing. You need to go through process one, with the right people and the right process focussed on the right outcomes in order to get something useful. Note that the domain model is only ONE of the outcomes.
If a BA comes to you with use cases and a BDOM you've already bought yourself a whole bunch of problems. The use cases can possibly be handled, but the BDOM is fatal. Here's why: if *anyone* who participates in the modelling has already come up with their model of the domain, it doesn't work. They simply cannot participate. This is from experience - we've seen it many times over, and have even had to excuse ourselves from some modelling sessions for this exact reason. It's human nature, that once you have a solution in your head it's almost impossible to see past that. If it's done in a modelling session, and you've got the expecation that modelling in groups will throw up many alternatives that you're going to merge together almost immediately then the dynamics at play are very different.
Added to this, a "BDOM" as is done alongside use cases is NOT a domain model. Since it's done alongside use cases it necessarily concntrates on the ad-hoc functional requirements of the day, and NOT on the domin.
So how to deal with it? If you can, don't let people even attempt to do BDOM's. If they insist, then ignore that artefact completely, and explain that they cannot participate in the modelling.
There are other posts here that talk about the "one model" issues, I'll try to dig up some links.
HTH, Paul.
Let's take the class diagram as our PD
Hi Paul,
thanks for your response and your thoughts about BA/BDOM which I fully agree with you :) . Actually the whole example is not from me but from Sun's SCEA Study Guide.
My point is how to bring there requirements into a shape that satisfy us in the FDD community. The only restriction that I bring in is to use J2EE's EJB technology.
For me it's a learning example on how to model not only the PD but also UI and DM. And what is better than to do this by an example. Let's assume that the class diagram which I've shown in my first post is our domain model. Can you live with that?
Now are my thoughts (see all diagrams) going in the right direction? Or am I wrong with it :( ?
Regards,
Darya
Missing Class Diagram
Hi Darya,
is there a copy of this class diagram somewhere public? I don't have a copy of that book.
Thanks, Paul :)
SCEA's Study Guide Not Public Available
Hi Paul,
all diagrams are in my first post. I typed them from SCEA's Study Guide - Case Study chapter, which is an example for Sun's Certified Enterprise Architect exam. The book is also recommended by Sun for use when doing the SCEA certificate.
Or do you mean whether the book is available for public? Unfortunately it is not :( .
Regards,
Darya
J2EE and Domain Models - Servlet/JSP
Hi,
looking at the issue of mapping a Domain Model onto J2EE technology - it depends on which specific technology you're talking about. The ones you mention are EJB's and Servlet/JSP, so I'll give you my take on those.
Servlet/JSP is easy - it's a UI layer technology, and so has no bearing on the PD at all. We've successfully delivered domain models, in the PD layer, that have been used to deliver a Servlet/JSP front end, a batch interface, and a rich-client all at the same time. That's not one bundled Java application, but the same PD codebase (e.g. in a JAR file) used in all cases without modification. This is due to the way you layer an application: the UI layer has knowledge of (and a dependency on) the PD layer, but the reverse is not true. This is standard MVC stuff.
On a practical note, the one thing we might see is that we introduce naming conventions along the lines of the JavaBeans spec so that JSP code can more easily access the attributes of PD objects, and traverse associations when necessary. But this is just fine detail, and has no impact on the model shape or design.
EJB's are another kettle of fish altogether. There's two parts to this story, session beans and entity beans, and the issues are quite different. Even for session beans there's two issues here. I think I'll leave this post where it is, and put the EJB stuff in another post.
So does help at all with the Servlet/JSP side of J2EE?
Paul.
J2EE's EJB for PD and DM
Hi Paul,
UI whether we use Servlet/JSP or Swing should be easy to handle.
Let us forget about UI and concentrate how to do the PD and DM with J2EE's EJB. Do you agree with me on the Session Facade? I think this one is the part the UI has only to communicate with.
To my understandig the Session Facade belongs not directly to PD, nevertheless I would put those facades into the PD package or would you prefer a separate package for them?
What about DM?
BTW, thanks for the discussion :)
Regards,
Darya
Facade = UI
Hi Darya,
In general, any Session Facade is part of the UI layer. More below.
With EJB's there's a few scenario's, based on whether you've got Entity Beans or not. I've not seen too many commercial developments based on EJB 3.0 yet, so I can't draw any real conclusions on that front. Prior to that most people avoived using Entity Beans like the plague.
So the most common scenario by far was to just use Session Beans, and implement some kind of Facade pattern. The real question is why? There are some situations where using an EJB container for some of its capabilities makes a lot of sense. These tend to be related more to non-functional requirements, such as hot failover, clustering support, etc. Note I'm talking at the application level here, not hardware. We're using talking about some stateful, complex interaction model to warrant this - it's quite rare.
With no entity beans we've got the most common case - a Facade implemented with Session Beans. Since they define the granularity of the remote communications (usually between the EJB container and the Web container) we make the calls as coarse as possible. This is done by looking at the interaction model, and how the UI is to be implemented to support that.
So in effect, the Session Bean interface IS the interaction model. If you change the screenflow or content of any of the screens, you usually have to re-do the session facade. We're clearly talking about presentation issues here, NOT "pure" business logic.
The key mistake here is thinking that the TECHNOLOGY boundaries are the same as the ARCHITECTURE layers. They're not. The "UI" layer in this case spans the JSP/Servlet stuff in the Web container, the remote calls, and the Session Facade in the EJB Container.
But here's the best part - the Session Beans are a self-fulfilling prophecy! Why? The only reason you need to do a remote call is that you can't put the Session Beans and the JSP/Servlet code in the same container. So because we're using Session Beans we have a remote call. So to deal with that we implement the Facade Pattern. Note - that's the ONLY reason in this scenario. And the best way to implement the Facade is with Session Beans. So if we didn't use the Session Beans, we wouldn't need the Facade, and so we wouldn't need Session Beans.
So the only reason we need Session Beans is...... that we're using Session Beans!
In this most common scenario, the whole EJB Container, Session Bean, Facade pattern, Data Transfer Objects, RMI stack actually delivers NOTHING. It's there to support itself, nothing else. I prefer to only build something once - in this case I'd like to build the interaction model into my Servlet's and JSP code and not have to propagate it across a bunch of technology for no benefit.
Contrast this to a simpler model: the PD and the JSP/Servlet UI layer all live in the Web container. We don't need a facade, since finer grained calls are possible. We don't need DTO's, since we have the "real" PD objects. Note that we still have all the other cool J2EE app server functionality available, for example transactions. We just don't have things split across two containers.
Of course, if you're using Entity Beans it's another story. It's just that most people don't, because they suck.
Paul.
DM and EJB's
Hi,
the question of the DM layer with EJB's is harder. It comes down to whether you're using Entity Beans or not.
With EJB 3.0 there's (hopefully) going to be no difference between using CMP and not using Entity Beans but rolling your own persistence with Hibernate (except for the container overhead). This could be good - we'll have to wait and see.
So without Entity Beans there's no issue - you roll your own DM layer as you would any other time (which is discussed in other posts on the site). For example Hibernate or TOPLink can integrate nicely with the containers transaction management if you want.
If you're using entity beans (pre EJB 3.0) there's two ways - Container Managed (CMP) or Bean Managed (BMP) persistence. The idea originally was that the app server vendors would provide tools so good that you'd pretty much use CMP unless you had some strange requirement it couldn't handle.
As it turns out, there's two problems. The first is that the performance of CMP generally sucks. It's really bad. I've known systems that have been built with CMP, and then had to be rebuilt from scratch without it just so they would run.
The biggest problem though is that CMP dictates a relational data model, but we're supposed to be doing OO with Java. We're back to the stone ages with the good old "impedence mismatch" between the OO and relation worlds.
What to do? Basically there's two approaches. The first is to live with it, and just stop pretending that anything about CMP is OO and go build yourself a relational data model based app. The other is to somehow try and hack around this inconvenience. The latter almost always leads to heartache. It's a hack, and hacks mean you spend too much time on the plumbing rather than trying to address the real business problem. If you're going to use a framework, in general trying to do things other than the way the framework authors intended is usually a very bad idea.
Since CMP was so horrible, the alternative was BMP. Early on you could use tools like TOPLink (and a few other that have since gone) and later Hibernate to manage the persistence for you. That's a good thing. What you got from the container was declaritive transactions.
Big deal. It's usually a *lot* less code, and a lot less heartache to do the same thing without the EJB container trying to help. Remember you don't have to be in the EJB container to participate in the app servers JTA transaction world.
Remember that the UI layer dictates transaction boundaries, and the PD layer only participates in them. So the UI "controller" code does transaction being/commit/rollback, and the PD code does the CRUD operations. So what happens when we put our PD objects into Entity Beans, and then put the transaction declarations on those? Usually it means some of the interaction design has again snuck across. Build any non-trivial EJB system and tuning the transaction boundaries is not trivial. Again it comes back to the interaction model.
So I guess my answer is: if you're using EJB's, you CANNOT get a clean DM (or PD or UI) layer separation. If you're using EJB 2.0 (or earlier) CMP, you don't even have OO - you're relational, and there is no object model.
Just remember, all of this is talking about cases where there's no justification for using EJB's at all. There may be, but they're usually non-functional requirements and so little of this applies. The technology inside the container is rarely what it's about.
HTH, Paul.
DM with DAO instead of EntityBeans
Hi Paul,
sorry for the big delay. I like to keep on with the discussion. After reading your answers I come to the conclusion that EntityBeans are not the way to go.
What is best practize in modelling the DM layer? What about DAO? Could I replace EntityBeans with Hibernate or JDO DAOs? You say that the CRUD methods are implemented in PD. I thought that is job of each DAO. Can you elaborate more on this?
I'll also discuss later on more topics in this thread that you brought up.
Thanks a lot.
Regards,
Darya
Modelling the DM layer
Hi,
I adated the DM and replaced J2EE's EntityBeans with DAOs. See the following model.
The DM layer is not complete but it shows the direction on how I think one can separate DM from PD.
I want your feedback. Is that the way we would do the object modelling for the DM layer?
Regards,
Darya
Relationship between UI, PD and DM layer
Hi,
please view next image and let me know whether this is conform with FDD's Object Model world.
The point is that I want to see whether I embedded the PD layer in a correct manner from a technical point of view or not.
I gave up J2EE's EntityBeans for DAO (w/ Hibernate or JDO) but still opt to use J2EE's SessionBean in the facade layer of UI.
What do you think?
Regards,
Darya
one difference
Hi Darya,
one difference that I would recommend is not to talk from the UI layer directly to the DAO's in the DM layer. We usually do this via the PD layer. So for example in the diagram you've shown, we would talk from the UI layer to the Order class in the PD layer, which would then talk to the OrderDAO in the DM layer.
There is one case where we might want to talk directly to the DM layer, but it isn't related at all to the individual DAO classes. Instead it is for handling transaction boundaries, or transaction demarcation.
The basic sequence of events for any UI is to begin a transaction by calling into the DM layer, then make a series of calls to the PD, which in turn makes calls down into the DAO's, which will participate in the transaction that has already been established, and then finally the UI will commit or rollback the transaction.
As a consequence of this approach, the PD *never* handles transaction boundaries. It will only ever participate in them, as defined by the UI that calls it. This makes sense, since the interaction model implemented by a particular UI is what determines where the boundaries make sense, which is something the UI should know nothing about.
So in summary:
- the UI only talks to the DM layer for transaction demarcation
- the UI doesn't ever call DAO's.
- the UI makes calls into the PD classes to perform any business logic
- PD classes call their associated DAO's as required.
- the PD never does transaction demaraction.
HTH. Let me know if there's anything that's not clear.
Regards, Paul.
UI call DM to instantiate DAOs
Hi Paul,
first of all thanks for taking up the discussion again.
When I understand you right my diagram was right despite a missing link from PD layer to DM layer.
The link between UI and DM is because the UI first need to create a DAO which in return create a PD object before the UI can call PD.
I fully agree with you on transaction.
What's confusing me is that you say:
- the UI only talks to the DM layer for transaction demarcation
- the UI doesn't ever call DAO's.
Isn't talking to the DM layer and calling DAOs the same :?
Regards,
Darya
One other question...
Hi Darya,
I do have another question for you. We're not using Entity Beans, which IMO is a good move. They generally suck. So we're left with Session Beans. So my question is:
What value is the Facade here? What is its role in this architecture?
I'd be interested to hear your opinions on this one.
Regards, Paul.
Facade encapsulates Use Cases
Hi Paul,
as you said in a previous response we need to have transactions somehow modelled too.
When I talk about Facade I do it in sense of the Session Facade J2EE Pattern which is a J2EE SessionBean. The values I get from it or better said from J2EE's EJB container are:
What I have not shown so far, is that each facade delegates to a number of service classes where each service class represents one use case. The service classes like any other class, despite the facade classes, do NOT depend on J2EE.
Another thing I also have not shown, which also belongs into the UI layer is, a Business Delegate and Service Locator to lookup the facade. A Client like a Swing GUI make its call only to the Business Delegates
Does it make sense :?
Regards,
Darya