ADDD in nutshell

The cornerstones of current and future application development methodology: ADDD

The abbreviation ADDD comes from Abstract Domain Driven Development. It consists of five essential elements. These elements forms the aspects of the method . The elements are listed in a list of decreasing importance.

  1. Understanding OO paradigm
  2. Creating an abstract OO-model from scratch
  3. Creating a logical 3-tier solution with completely isolated domain layer
  4. Working in agile way from the domain model to the implementation of applications.
  5. Generating code from domain model.
  6. This is all there is to be said

This will cover the most important methodological principles and guideline of the process. The rest is just refinements of these elements. The method can be described as top-down. Here a grouse big picture is created quite quickly and thah starts the incremental and iterative phases which proceeds from the abstract model to detailed set of applications. The true nature of this process is twofold. First phase reduce the amount of detail to create clarity and understanding and the second phase – the construction phase- will bring gradually back all the necessary detail. This construction phase must be both incremental and iterative because of the complexity. We have actually learned (very) hard way that it is far beyond human capacity to fully design first and implement second.

1.     Understanding OO paradigm

This is fundamental requirement for the whole thing! People doing this must fully understand what OO means and who in functions. The step taken from ER (entity-relational)- modeling to OO is the addition of the behavior within the world structure. As in the previous procedural approach the behavior was described as flow of named events in OO the same behavior is described as objects’ internal behaviors as well as collaboration between objects. This difference is totally fundamental and is the only real and big issue that separates it from ER. Without fully understanding this there is no way forward.

Figure 1 The two paradigms

2.     Creating an abstract OO-model from scratch

The second thing is to know what a practical (working) OO –model consists of and looks like. Here the paradigm from bullet 1 start to have a defined form. OO-model consists of a class model and a set of most important collaboration diagrams. The class model can be visualize with one class diagram and/or several diagrams of some subsets of the model. This model is the most crucial single entity during the whole development. Getting this right is very important. I will present the whole issue of the abstract domain model and modeling in a separate post and add here just a few remarks on this subject. The starting point for this model is a chosen subset of reality. We are to create a model –i.e. simplification – of this target part of reality. To create a simplified picture of something is a delicate task. We rip off detail to emphasize more important aspects from the chosen point of view. The work proceeds actually other way round. We start with a small set of most important identified concepts. Then we add some attributes and most natural behavior in these concepts. Then we add most important association between these concepts. Finally we start to describe the most important behavior mechanisms that these objects will perform. In the next phase we add new less important concepts in this picture and repeat everything above. At this point we start to have our first version of the class model in place. Now we can create a few collaboration diagrams that will clarify and verify that the structure and behavior of our model is correct. The analysis phase with the creation of the domain model is also very iterative. I have done over hundred of this and my experience is that almost never the first version of the model is good or even acceptable. One seems to need from three to eight iterations to achieve good quality outcome. When I am teaching the abstract model I use to say that these drawings are not (only and mainly) end results but they are rather tools for developing understanding.

The key thing in the abstract modeling is to keep the level of abstraction as low as possible without exploding the number of classes. Quit basic thing is to name the classes with names that come from the domain business and are the terms that business people uses daily. In most cases the total number of the classes in between 30 and 80. It should never exceed 120. The number of associations in such a model is between 2 to 5 per class. In same complex environments this can be exceeded.

3. Creating a logical 3-tier solution with completely isolated domain layer

The next phase is to design and implement the application. There the first thing we need is the architecture. This is the structural pattern that the community came up with and it is still completely valid. The logical structure consists of three layers: Application, Domain and Persistence.

The OO domain model is the simplest way to model reality (in this case a business) to create a operation control system for it. This chosen architecture still improves this. Here three different aspects of the implementation are separated as strictly as possible. The first finding is that the executing business model needs no bindings outside itself. So it is very self-contained. So the coupling between application layer and the domain layer is one-way dependence the same thing is almost true between domain layer and persistence layer also. There is one small additional option. Every object have to know a handle in persistence layer to be persisted. This is not actually very serious, because it increases the complexity only linearly.  So this picture is enhanced to a new form:

4.     Working in agile way from the domain model to the implementation of applications.

One thing that has caused us a lot of trouble is the “waterfall” development process. It has been completely clear at least a couple of decades that this approach doesn’t work but good alternatives have been missing. Currently the experiences from research and car industry practices (especially in Japan) have changed the situation completely. Today it should be crystal clear for everyone that every waterfall project is doomed to fail but still we can see that being tried. Today agile and lean are widely accepted (at least in theory).  Scrum is commonly used to develop software. On the other hand incremental and iterative ways of working have also its own difficulties. This way of working was promoted in early 1990’s named RAD (Rabid Application Development). Most of those projects started as hacking and ended in catastrophe. The same symptoms are experienced form time to time also with Scrum. If with Scum development the team  doesn’t create in one way or another some kind of overall understanding and guidelines in the beginning then it most probably faces a extreme refactoring in third or fourth sprint when this structure gradually starts to unfold.  To avoid these drawback ADDD start with abstract domain model. This is abstract enough so that it can be developed within a few weeks but at the same time it contains enough domain semantics to give the overall world structure and most important behavioral mechanisms. This will give a good starting point and development guide lines for the rest of the implementation project. The abstract domain modeling is done by a group of business people and a modeler. This activity takes from 2 days to max 15 days of fulltime work from this group. The active is done in working session where the whole group is all the time present. Typically I have had half day to 6 hours long sessions and ideally a session every second working day. In this way the model contain typically 30 -60 classes and 40 – 80 association between classes. It also has 5 – 10 collaboration diagrams showing those most important business mechanisms. When this is done the rest of the implementation is done as typical Scrum project that use the domain model as starting point of the domain implementation . The Scrum process introduces the required application workflows and features gradually and this way an application by applications is developed. Long experience tells us that the abstract domain model in most cases includes almost all the classes necessary for the implementation.  The application development phase will bring along the additional attributes and services.

5.     Generating code from domain model.

The last aspect of this development process is the code generation. This is also the lowest in the priority list. The generation is possible only in domain layer because this is the only layer where something is done before implementation.

From abstract domain model one can generate classes those attributes that are present and all the associations as well as the business method signatures and navigation method for single attributes as well as for the collections (getter) and some of systematic creation methods as well.  This navigational transitive closer is most valuable part of the generation. The domain layer is from 15% to 30 % of the overall implementation code.

The application layer is in average more than half of the whole code mass. The nature of application layer is to create the most effective work flows for each user group. This is always essential key to success and at the same time a learning process for the organization. These are the reasons why even in theory there is now way to generate the essential solutions. Complete other question is the current lousy tools available for this work. Those tools can indeed be improved dramatically!

Persistence implementation should not be visible for the system developers at all. As long as the infrastructure lacks the feature it must be added into each application. Best solution is an object database, next one an ORM (Object – Relational –Mapping like JPA) and the worst some kind of old database and a hand coded DAOs (Data Access Objects)

6.     This is all there is to be said

In methodological sense after our long journey, we have arrived at the top of the mountain. From here whatever way we chose that takes as back down again.  So in a way the development of application development methodology ends here!

One Response

  1. I forgot one point.

    You are right when saying navigation diagrams are not often used.

    I believe that the business computation rules are almost impossible to automate because they are specific to each business component, in their definition and in their workflow.
    So I intend to associate to each business component a current state persistent and a (H)FSM with the hope that reuse will be possible by considering graph patterns associate to state workflow and that standard traversal will suffice.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: