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:

 Image