Effective & high quality as an end result of applying my method

My ADDD application method is a very pure continuation of OOA – OOI development tradition.

I do not know any other quite similar. The starting point of my method is of course 3-tier architecture, but this is nothing special and is dominant in all OO approaches. This is more of a result of more fundamental aspects.

The cornerstone of the method is the idea of abstract domain object model. This fundamental carries with it two dimension: a special processing sequence and the architecture of the outcome.

The time dimension of the process is very important. It is very important to create a domain model with domain experts. The whole model creation process in a very delicate matter. The domain OO model creation should ideally start from scratch. This however requires a very experienced modeler because according to my long experience it ts quite difficult to do it well. For this reason I have created here very general a few business field domain model so that people with less experience could do better studying that first of using id bases and modifying their of starting from that.

Anyway this domain creation process should consist of half to full day session and at least two sessions per week. The modeling group should remain the same during the whole modeling phase. It is very difficult to take new member on boar later in the process! This activity shouldn’t take longer that totally 20 working sessions. If it is taking considerably more, it is a sign of very bad mistake: creating too detailed model. The final abstract model most important feature is to give that structure or topology of the reality. So the fundamental ( = abstract) structure of realty is reflected in the class model of the domain.

The domain OO model consists of n + 1 elements. One class model diagram with 30 – 60 domain classes and n collaboration diagrams describing the most important domain processes. One important point of this model is that is stops too much detail surfing too early. The most daunting enemy and evil of software development is too much detail too early! This is everything that comes out of the modeling.

Use cases are also consider useless and harmful! The have at least two vicious features. First the forces into design before analysis is completed and second they tend to push details up to surface.

After the domain model is created the it can be implemented and tested. O yes way before any application layer is design! The nice thing in domain implementation is that quite a lot of code can be generated from the model itself.

An important aspect of this cornerstone is that in implementation the middle domain object layer is completely and totally isolated from the rest of the implementation. This means that this layer is completely unaware of the other layer and don’t know who is using it and why!

After all this is completed we can proceed to design the application layer. Here the emphasize is on the word design. This is where we create new and design the work-flows in the application to make the work as easy and straight as possible. Of course this layer have to know all about domain class structure and all the association that it needs. This is also true for the services the objects at hand can give.

Here the use of use cases is not that harmful as it was in the previous step, but it is not necessary either far from it. Actually one can easily do also this with collaboration diagrams

The third layer is of course the object persistence. I am advocating OO- databases but it depends on circumstances and one can do it with ORM also.

Finally why this is true. Well here is the theoretical foundation of this. It is the balance between the amount of coherence and the number of entities and their relations. Here is a graph that gives you the overall complexity minimum:



A real CRM system

I know very little about commercial CRM- system. I have been very doubtful about them since they appeared on the marketplace. The only reason is that customership is not a set of attributes in a company or a person. It is in a simple form a relationship between a company or a person and a set of our (my) products.

When a relationship get a bit complex is needs an abstract even to give it flesh. In this way we can associate more things to it.

This is why a real CRM- system always contains the whole product portfolio and in fully integrated domain driven model also the whole production system to some extent. In this way CRM is always part of ERP!

I created a quite abstract model around the customership event object. Here it is:



The moto is: There is no customership without a product!

Event Management model

Here is small and quite practical domain model of organizing different kinds of events – like congresses, fairs or festivals. All these events can have several parallel tracks and each track consists of consequent sessions. Sessions have a subject or a tittle and from one to several performers. The members of listeners or audience are called participants. A sessions is event-moment type of object and all different roles are connected to the event trough participation-events. Each participant has exactly one participation event to connect the person to the event. Participation’s state attribute in the event reflects the life cycle of that event.


I am trying to implement this model in an event management application. The application will provide means to register to the event and then the application will confirm the registration if there is available capacity left.

I am implementing this with Python and I am currently testing ZODB oo-db with this. I am still looking for a web framework. In my first tests I used tkinter GUI. I like the lightweight but oo structure of Python. It remains me a lot of Smalltalk with it’s dynamic oo variable binding.

Let me train your developers in Object-Oriented paradigm and modeling

There is a lot of undeniable evidence of the high productivity of Object-Oriented paradigm.
The core of the reasons behind this is the simplicity of two layer structure of all activity.
When all activity is divide in two parts: the things that each participant achieve individually and what is the result of two or more individuals collaborating together.

The paradigm sift from procedural to OO in early 1990’s was a total discontinuation point. It seems that the huge majority of “the old school” veterans that had not enough training and resources to understand the hard core of the new paradigm and the poor new tools together caused the whole computing community to deteriorate back to the “golden age of algorithms”. This way we mentally retreated at least 15 years in software development methodology.

Today my guts feeling is that most application development projects are conducted in an extremely inefficient way. Thus those cost many time more than would be necessary.

Agile development is one step forward and an attempt to do things better but it deals most with group dynamics only and it requires strong methodological support from the professional side. OO is that counterpart.

Software developers should be much better of if they were not taught any 3G procedural languages and databases at all. All this stuff belong ti the past. Instead the should be taught domain modeling, object behavior and collaborating sets of object, object life cycle and persistence.

When a person has learned to develop a Java application in modern IDEs then it is not a big effort to learn the OO paradigm if one is to learn it at all.

I think that the current development teams should give their member a fair chance at least to learn to know the cornerstones of the OO-paradigm and the development method to be able to compare the methods and to decide them selves.

It takes only 2 – 3 days of on-cite training to open peoples eyes if that will happen at all.
I am most willing to give that training.

How to learn object-oriented domain modeling?

I have taught quite many people their first steps on their path to domain modeling ( more that 1000 persons).

These students have had very many kinds of backgrounds. More that have have been IT-people and majority of them have had high education in computing. The rest of them have been the becoming users of those target organization developing their applications. The education and profession among these people varies a lot. So I have very wide spectrum of experiences trying to explain what an object-oriented mode is.

The fundamental requirement to start the journey is the basic understanding of OO. These are “the rules of the game” like the basic moves of the piece types in chess. If you don’t know these you just can not play!

In OO the most fundamental aspect is the concept of object. Object is a “whole” is has to sides structure and behavior. In OO there is no behavior without at least one object. There is no action or behavior outside objects! If one doesn’t get this then there is no hope. It seems that there is small part of people, for whom this is too much or too difficult!

When one has accepted this, then the journey can begin. The first and most fundamental feature of and object is that they all are unique in the whole timespan of the universe. This fact is reflected in the identity attribute of an object. We could agree, that the ID attributes are never shown in the model but every class have one. It is also important that the ID attribute is not combined with and other natural attribute. The second thing that I always teach to my student is that all object has a life span. So what all objects have in common are birth and death. Actually in OO the biggest issue is how and why objects are born and die. When one masters this then the rest is really easy.

When we start to create an OO- model it is easiest and most natural start from static features and start to create class model. It is always easiest to start from concrete sustainable things like house or person.

When we start to create a class model with class diagram before drawing the first class box just list a few names of the most obvious class candidates. The very first crucial thing is the name of the class! I should always be chosen with care.

At this point one should also name a few ( 2- 6) most relevant attributes to give shape for the class with a brief description of class. In most obvious cases the description in unnecessary – like class Person, but if there is any doubt or the usage is in any way restricted then write the description.

Almost immediately after you have a few class in your diagram you should add all necessary relation between classes. Most important of these is association. These give the world semantic shape.

Now it is time to open up our example model. This is the simples possible model and I have used this for modeling trainings as well as for Java-trainings.

The domain is is a classical bookstore. The model will be quite abstract to keep it simple. Let’s start with very concrete classes. The fist one is a class that I have had in almost every model that I have done. It is Person- class. In this class belongs about 7 billion individuals on this planet. The other completely obvious class in this domain is Book. If we want to lift the level of abstraction we could have chosen the name Publication for this class also. I will use Peter Coad’s color notation in my UML- diagrams.


I have left the ID attributes out from this model.

When my students have worked with this model the Book class has proved to be somewhat confusing. The type of objects that belongs to my Book class here are the contents of the books. In concrete terms one could think that my book is actually the original manuscript of the book or the copyright of that book and not a single print or other kind of representative of that content. This is why I have an attribute inStock, which is the number of copies of that particular book in my shop.

The next thing to consider is perhaps the most challenging aspect of OO- modeling. Jim Rumbaugh described it: “objectified events”. This means that when OO model consists only objects and to enable us to include event also in the model, we have to change event to objects. Well there is no magic in this. Event/moment object is an object which is an abstraction of time slot. This means that every event-class has two attributes: start time and end time (sometimes this can degenerate to time). The color for moment/event is pink. More advance is to model behavior for this events.


When we consider what are relevant events in our domain considering the business in this context. When I have asked this question from my students almost always the answer is purchase. Well this is really the most prominent event and right answer, but here is also an other not so oblivious but from the sale point of view more interesting event is Walk. This is an event that enclose the customer’s visit to the shop from the event of entrance until he arrives to the cash. Here are the two events:

The behaviors of a Walk object are for instance pickup a book, end the walk, return a book that has earlier been picked up. A purchase is responsible to carry out the transaction.

The last step with class model (and diagram as well) is to add all the relation between classes. In this case we don’t have any inheritance so all the relations are associations. The digest category of association between entity classes and collections. For this reason this type has a graphical notation (a diamond). An association between a entity object and an event object is almost always participation. So the associations in our model between entity objects and event object are participations and then there is an association between two events. The type of that is creation or “mother”. Here the walk object creates the purchase object. So our full class diagram is following:


Now we move deeper into the dynamic of the model. The tool that we use is collaboration diagram. The name here is important because the diagram presents the process the sequence of action where a set of these objects in collaboration with each other achieve some important goal. Here the key process start from entering the shop and end at the payments of book bought. So this is the process that we have to cover and describe with objects. The steps in this process briefly: 1) entering the shop: the person object creates new walk object. When the person finds an interesting book and takes it with him: person object sends a message pickUp( the book) to the walk object. When the person decides to end the walk: The person object sends end() message to walk. This will create the purchase object and finalize the purchase.


Now our abstract object model for our bookstore is ready to launch the next step. These model are never finished but they are ready for advance. Modeling is both incremental and iterative process.

This process cannot be automated and there is no set of rules that would change this process routine or trivial.

This all means that it is quite easy to create some OO model representing reality, but the quality of the model can vary dramatically. To archive a meaningful abstraction that really help understanding the reality requires very high skill and experienced modeler.

The walk objects are actually the strongest tool for sales promotion. They can also give weak indications very early where the market is going. When I am giving my two day training after going though bookstore I will give the first exercise for my student. That is following: Create a model of library, so that it cover lending a book and returning it. The first question here is what is the most important event in this domain. In many cases the students quite well learn from the webstore and bring in walk event. But in the library model (at least if we think it is a public and free service like in Finland) the walk is a possible event in the model but of course the loan event is actually the most interesting one(and actually the only necessary event).

High productivity in software development

It is relatively easy to show that abstract domain model driven agile application development is at the absolute complexity minim within all know application development methods for von Neumann computers.

This means of cause that this is most productive way to do it.

This method starts with creating an abstract domain model for the organization from scratch. This activity can takes up to 15 working days from analyzing group but in average is less than 10 working days. The result is something that I call object-oriented abstract domain model. It consists of one class model (named classes, a few essential attribute, core business methods and all class relations: associations and inheritance trees).

This abstract model states the essential business process requirements in a very rigid object-oriented languages. This is actually the most compact and coherent presentation for these requirement.

The next step is to design the necessary work flows into GU-conversation that are based and supports the earlier created domain model.

The implementation follow the three-tier architecture, where the domain layer is completely separated from the rest of the code. The implementation start from selection the hardware and software platforms for this implementation. The next step is to generate the domain layer skeleton from the domain model. After this the implementation proceeds incrementally adding both application and domain behavior simultaneously. This all happens in close direction of product owner and the becoming user community.

The ratio of the code sizes between three layer are typically following. The domain layer including all business logic is between 10 – 20 % of the code. The size of persistence layer varies the most depending on selected db solution. This depend heavily on the environment. If one has several old databases behind the new solution, this will require substantially code between domain objects and databases. If one can use one new relational db, then one can use JPA framework and reduce this work. My favorite is object database, which end up with least work. So this layer can be from a few percentage up to max perhaps 40 %. The application will then fill up the 100%.

The model generation will create in average 50 – 90 % of the final domain layer code. So if your ready application consists of 100 000 lines of Java then the business layer take 20 000 lines and all business logic methods about 4000 lines.

I have published here business line abstract domain model. Still I insist on doing it “ from scratch”. The model I have provided here should be used to guideline the modeling and they can be used for jump start for a novice modeling group to avoid very drastic mistakes. The model is after all the hart of the system and its design. Its influence to the whole system is many time more important than its ratio in code lines.

In may next post I will tell my experiences on how to learn to analyze reality and create these models. When I start doing this 20 years ago I thought that this is very easy for all of us but I proved bitterly to be wrong in this!

Profile of my 2012 blogreaders and review

I will thank all my readers for yet an other year of your interest to my views and ideas on OO -paradigm and agile domain-driven application development.

The WordPress.com stats helper monkeys prepared a 2012 annual report for this blog.

Here’s an excerpt:

600 people reached the top of Mt. Everest in 2012. This blog got about 11,000 views in 2012. If every person who reached the top of Mt. Everest viewed this blog, it would have taken 18 years to get that many views.

Click here to see the complete report.