My contribution to ADDD.

The start of OO

The classical OO- analysis and design is the cornerstone of OO application development. From those early days of 90’s come the fundamental ideas: domain classes with private attributes and private and public methods placing business behavior into domain layer and splitting the implementation into logical 3-tier architecture. This is all extremely vital also today. Actually almost nothing has changed in these respects that would affect their importance or value.

Popularity and expansion

Along 1990’s when OO gathered popularity and more people where involved things started to screw up. Bigger projects where started with less trained people. To ease the confusion Ivar Jacobsson introduced use cases. The result turned out to be almost the opposite. Many people were confused about use case’s meaning and role. The difficulty with those was (and still is) that they are not actually part of OO neither notation nor concept. Actually wrongly use they can be completely overlapping with the real OO notation. The heart of the problem is very fundamental. When people tried to do more complex things with OO they run into the problem of abstraction levels.  (there are more detailed posts on both previous subject in this blog). The consequences of this all was that people started the development  at too low abstraction level and they were hit badly by the combinatorial explosion and as always when a team starts to use a new method or discipline and they are not enough trained the method get the blame (of course not the people)!

My findings are:

First I studied the relationships between the layers in the logical 3-tier architecture. It was evident (and often told allowed) that the responsibilities of the layers got mixed in the real implementations and the more inexperienced implementer were the fuzzier the layers became. In the early days all the gurus advised to start from application requirements and work through application controls to domain layer. In most cases this ended to a catastrophe due to rabbit complexity growth.

My analysis came about with the following corrections:

1) Tight couplings:

Domain itself is always tightly coupled within itself. This actually is the pure meaning of the domain. Theoretically (and in practice too) is forms a transitive closure.

Both outer tiers are tightly but at the same time asymmetrically coupled with a subset of domain. Asymmetry means that the outer tier is tightly coupled with domain but the reverse is not true. The domain is not at all coupled with application tier and each domain class has exactly one hook to the persistence tier. The domain doesn’t know anything of the rest of the world. See the next diagram:

Coupling in 3-tier implementation

2) Timing

All the old gurus suggested to start from application requirements. I think this is wrong! Thus my first modification is on timing: Start from abstract domain OO model without even touching the application part. This means that the business behavior (rules) must be modeled with object collaborations. This will imply that the domain OO model is modeling a subset of reality of which the organization is interested and where it operates.  Here the emphasis is on by whom not how. Of course the where also includes how, but the point of view is that the organization is not acting alone but rather where and how it interacts with others. So this model is actually a subset of reality not organization. Starting here actually implies that the domain modeling is about understanding complex reality and is the least interested in any current or future IT system what so ever.

Start from a “clean table” and first do your analyze on concepts and bring about your initial class structure. By the way UML class diagrams are end results but their versioning is an instrument. Without drawing things wrong you cannot draw those right.

3) Control over the level of abstraction

The second thing is to control continuously and knowingly the level of abstraction. This is very important as well. The main goal of the initial domain model is to understand and to get a grip of the target reality. Thus here the most important task of  the modeler role is to keep the amount of detail as low as possible and still get as much structure and semantic as possible. These goals are evidently contradicting so you have to try to balance between them.  In the initial abstract domain modeling phase the amount of classes increase rabidly close to implementation phase level but the number of attributes should say quite low during the whole abstract analysis. An average amount is around 5 % – 25%. It should never (even in very small models) exceed 65 %. The final set of attributes should be discovered though application (UI) designs.

4) Abstract analyze phase

The responsibility to create abstract domain model belongs always to people with best operational knowledge of the business. If the group includes also top management decision power this will ease and speed up development but this is not in any way necessary. This is always group activity. It is extremely important that most of the important interest groups are presented. The starting phase is conceptual clarification and language calibration. Actually this gives the language of the business. Of course there has been a language before this, but this is excellent opportunity to create crisp sharp edged concepts and their relationships. The name of this all is an abstract OO domain model. This phase takes typically 3 – 10 working days of the group. It should be intensive enough an optimal timing is 3 * 6 h session a week for a couple of weeks. This should ever exceed 15 working days. During this process will be created 3 – 10 versions of the domain model.

5) Application design & implementation

I am convinced that agile methods are the best way to implement application. But before the development SCUM with its sprint cycles I think that it is wise to have this abstract analyze phase before it. The iteration starts from analysis domain model that is generated into some OO -programming language for instance into Java. The development of different use cases of the application can happen almost independently. Of course there are common parts (GUIs and control) that can be shared but even this is not necessary. Each iteration will add new attributes into domain. The need for these rises from GUI and workflow control.

Considerations

Is this difficult? This subject divides people. Some of us think this is difficult others don’t. I have considered this (all my live) easy. The basic think is to grasp the world as a stage for individual actors to collaborate. If one see the word in this way: collaborations of autonomous agents, then there should be no obstacle to consider OO-models easy. I actually get support to this view, when I create object diagram to illustrate some important or complex single case instead of class diagram.

One or the professional skills here is the ability to read class diagrams. All professional OO-modeler have to be able to “see” though a given class diagram all the possible cases that yields from this.

*ADDD ( Abstract Domian Dirven Development)

Advertisements

2 Responses

  1. Excellent site, keep up the good work

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s

%d bloggers like this: