The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

sim085 (3) [Avatar] Offline

I have nearly read the entire book POJO in Action so far, and considering my level in Software Development I really found it as an eye opener and must admit I have learnt a lot from it.

However I have a question to which I still do not have an answer yet. I have read several books and internet articles but to no avail. I believe this question does not go out of the scope of the POJO in Action book since it is mostly related on how to develop full blown up applications using POJO’s

Basically working as a software developer puts me across user requirements that are not aimed to solve only a single business process (Use Case), but many. I always try to modularize these business processes. However when I come to developing the application I finish coding all these processes into one single project, which means one single very complex domain model!

Although on paper (UML diagrams) the domain model is modularized, in the actual code (which is what usually gets maintained) it is made of a set of intertwined objects which in the end confuses people.

In my opinion, having one domain model defining more then one business processes can have several disadvantages. First of all, the domain model becomes to complex which in turn becomes too hard to understand and thus to support and maintain. Also, having a domain model solving just one single business process means that it is a much easier task to change that implementation when the business process changes.

However one should also take in account that a domain model aimed to solve a business processes could have the same objects used in another domain model solving another business process.

So now I will use the ‘Food to Go’ example to make my thoughts a little bit more simple to understand. First of all let us imagine that the owner of the ‘Food to Go’ company now requires that only registered user can order food over the internet. Also he now wants to add a ‘Critics’ area related to each restaurant where everyone can see the different comments, however only logged in users can leave comments on a particular restaurant.

Above we now have two (2) new business processes.

1. Users must now register a username and password before making an order.
2. Users should be allowed to enter comments on different restaurants.

All the above changes could very easily be implemented in the already existing domain model. However before doing that I keep in mind that tomorrow, the owner of the Food to Go Company could come with more Use Cases. (My first question smilie Will I continue creating new objects in the same domain model? Wouldn’t this mean that one day I will finish with a domain model too large and intertwined to maintain?

The following is what (right now, with my experience, which is not much) I would do:

I would try to develop a domain model for the Logging in and Registering (2 Use Cases). However this domain model would still have to expose the User object to the other domain models since this object needs to be used to determine if there is a User has enough privileges to do something or not, or if this object is not in the session, then it means that there is no user logged in.

The second bussiness problem requires that the user can view all the registered restaurants and if logged in he could then leave a comment (2 Use Cases). This means that with the domain model developed in the book I would be adding a Comments object. Also I would require the User object from the Login and Register domain model to know if a user is logged in or not.

However my question is how? Maybe I am too vague, but how to develop a domain model that will not over explode with time, and thus remains simple to understand and thus support and maintain? Is this just a game of playing with package names?

If we look at live examples, we can see websites like the one of Sun ( which I am pretty sure that it is not all defined into one single domain model.

Basically I lack the understanding on how to develop a full blown enterprise website which is definitely going to continue growing.

The above question (which I am sorry for being so tall) has a lot to do on coding as much as it has to do with deployment. If the domain model is very large then it will start taking ours to test the entire domain model. Also compile times will continue to grow and grow and grow!

I am sorry for writing so much. To keep with the spirit of the manning books I will write a small summery now to try to explain all the above:

How to develop a domain model that is designed in a way that it can be easily extended with out finishing having a single domain model too complex to understand, maintain, test, build and deploy?


ps: I do not know if there are books discussing this problem, however if there are, then you could just refer me to those books, and I will be more then happy to read them smilie
sim085 (3) [Avatar] Offline
Re: Best pattern to develop a very large domain model with POJOs

(Writing this just in case someone has the same question)

From they sugested that I should search on 'bounded contexts'.

simbo1905 (30) [Avatar] Offline
Re: Best pattern to develop a very large domain model with POJOs
I definitely did not know the solution to this sort of problem back in 2006. The answer i would give today is to explicitly model workflow (business processes and user tasks) as part of the domain model. We now use embedded jBoss jPDL library to explicitly model workflow in the system. It give you lots of value add such as a graphical workflow editor and process fork and join. Once you model workflow and process separately it is clear how to add custom code to the steps in the workflow or the transitions in the workflow that work with a re-usable Domain Model of classes which models the "what" and "how" of the system independently of the "when" and "who" which can be modelled as a workflow Service which is implemented via jPDL.