In some books there is written that you should divide your Domain Model into components.
So you would have an Article component which contains several Business Objects and another Supplier component which contains its own set of Business Objects.
But I believe that the Business Objects are very interconnected by nature. So a division into components makes no sense to me. Often we have to change 2 or more components at the same time because of these dependencies.
Then we apply the idea of unidirectional relations. For example Article has an instance of MeasurementUnit but not vice versa. But this leads to problems, for example when validation is used. Lets say that attribute x of MeasurementUnit is only allowed to contain more than 3 characters if attribute y of Article is equal "yabbadabbadoo". This would not work because of the unidirektional relation. So we woul need bidirectional relations. Lets imagine MeasurementUnit would be a BusinesObject of another component. If a bidirectional relation between Article and MeasurementUnit was designed, then there would be cyclic package dependencies.
This is just a short summary of the problems.
Because of these problems I believe that unidirectional relations and division into components makes no sense for a Domain Model. I mean a model with Business Objects like Article, Supplier, Address, Country, Order, Sales and so on. Everything is highly connected by nature to me.
Please tell me what you think about my opinion.
I fully agree with your observations.
As far as components go, putting two classes into two different components when one is type of a member field in the other makes no sense at all. Anyway, EJBs are usually deployed as a set of session beans which operate over one set of classes. So you have many components, but just one, undivided domain model.
Unidirectional relationships are IMHO an unfortunate leftover from C. A usefull OO language would offer bidirectional relationship as first-order construct, but noone has bothered to do that. Implementing them by hand takes a lot of effort and is bug-prone. Because of that I wouldn't even try to create a domain model if it would be heavily interconnected.
Anyway, (OO) domain models are overrated. They are a nice conceptual tool, but are a tarpit when implemented. Instead of domain model, design "domain objects" as "typed" ResultSet rows. So don't do inter-transaction caching, put no behaviour into them and most of all, create new "domain class" even if its attributes "overlap" with another class.
I completely agree too with the original post and Bostjan's comments.
Domain models make sense conceptually, but implementation confuses them until they no longer can possibly server their original intended purpose. I'm taking the mindset of having stateful/behaviorless domain objects that are direct mappings of the ResultSet, but leave it up to my Application Session beans to coordinate interactions between domain objects.
It seems like the application requirements drive the domain model, but then you end up in sticky situations where on some screens you just need the manager name tied to an employee, other places you need all of the manager's information-- how best do you design your domain model to match both cases?
Once again people confuse the views and pages that display data with the actual data. In pure OO the business or organization view should rule. Forget the implementation of the web pages or screens. If the domain model follows the rules of the business then you have done a good job. People get so worried about performance and pages that they ignore good OO design. I use a domain model and it is great. I have strong validation built into it so I do not need to reinvent the wheel on every web page.
This doesn't mean I ignore performance. Some domain objects may have duplicate data to facilitate queries and such. But those are add-ons to the model and are documented as such. If someone wants to see how the business views its objects then out domain model is an exact map. And yes there is tight coupling, but this does provide the payoff that we have correct validation and control. Let frameworks and AOP be flexible. A business has very definite rules and if they are not correctly enforced then chaos will reign.