Dynamics of object creation

A fundamental starting point is that all the classes in a domain model are connected. This means that there is always an association path from one class to another.  In most cases the creating objects are directly associated with the new object. On the other hand domain layer objects don’t have any reference outside the domain. All domain objects must be created by a domain object even if the stimulus to do so comes almost always from outside (from application layer).

When an application usage starts, some entity object exists. So creation of these objects is out of the scope of the application. Of course technically every object of an application must be created, but this is not the issue. So a set of objects exists and are in a way given to the application. In most cases for example the home organization, its roles and persons exists.

Now when we start to analyze object creation, the first fundamental base finding, that by the way is easily passed by beginners, is that an object cannot ever create itself. The next issue is can an object from the same class create an object from the same class. This is true from some classes and not true for others. For instance object in Persons class can create a new person. Now actually this needs two objects from person class and 9 months – but serves as an example anyway. An example of entity class that cannot create an object from same class is the class House.

When we take into account the Coad’s color categories then we can be more precise. My first examples were bots entity-type classes. So we can say in general that some entity class object can create object from the same class.

Role-type classes are actually objectified associations. There is even no theoretical aspect why a role object should create similar objects. The same applies to Description-type as well as to Event –type.

Typical creation patterns

Let look at different dependencies and situations at object creation. Let’s go through Coad’s categories what are the creation patterns and their justification. The bottom line here is to set the behavior into an object that “knows” most or best what to do. This seldom corresponds strictly reality instead some level of abstraction (read imagination) is needed.

Creating Entity-class objects

As I already mention some entities can create similar entities. Here are some typical patterns to create entity objects. One example of these abstract ways is the first very common entity creation pattern.

Creating entities from descriptions

Here the idea is that we have a description object, that describes an entity. The responsibility of creation is put in this description. Let’s take a couple of examples: The drawings (the design) of a house will create (read build) the house. A recipe will create (read cook) a meal and so on. In reality this description in most cases is unable to do this, but the abstract way of thinking this is that the description is the actual performer but it uses something of someone in reality as an instrument to do so. In the case of a meal the instrument is the cook.

Creating entities  from events

Similar to description are event. The production of entities from can also be modeled with and event object. In these cases the responsibility of entity creation is typically but into the event. For instance a cook event can also be considered to be responsible of creating a meal. This is an alternative solution instead of the previous one.  The need to have the event in the model instead of just a method is the need to know something about this event itself. Simple example of cook event could be the duration.

Creating Description-class objects

This is very similar to entity case. The domain stories often starts from a description, so they are not actually created within the domain but rather outside. Of course the application layer have to have a functionality to crate object that are starting points of the domain behavior. This is however another story.

Creating Role-class objects

In most cases a entity object will create a role for another entity. This creation of a role enables this entity to participate in some activity. For example a role of developer have to be created for a person by the organization entity before it can be associated for instance I a project task.

Creating Event-class objects

This is perhaps most flexible category. Entities, role are typical creators of events, but event can be created by other events and descriptions as well.

My approach and My training

My paradigm is ADDD (Abstract Domain Driven Development).

(see: https://jukkatamminen.wordpress.com/2009/08/06/my-contribution-to-addd/)

This starts with abstract domain modeling. The next thing is logical 3-tier architecture and the third is agile application development.

First my working principles on abstract modeling are:

  1. Abstract OO models from reality.

I am specialized to create abstract object-oriented domain model. These models are representations of reality –not any application. The models actually have very little to do with applications and even that little is pretty indirect.

  1. Modeling process

These models are always done from scratch. It takes always from 3 to 15 working days from a modeling team. The only way this can be done is a workshop that every participant participates practically every session. The technical modeling and the required facilitation is done be the modeler ( in this case be me). The session length is 3 to 6 hours.

  1. The deliverables

The end product of this activity is always a class model and a few collaboration diagrams. The class model is represented most desirable as one class diagram. This class model contains 20 to 70 classes and their associations.

Second thing is 3-tier architecture.

  1. The layers are: Application, Domain & Persistence
  2. Domain layer has no references out side itself.
  3. The best persistence layer implementation is a object database.
  • Consulting  domain modeling

The most important element in this process is abstract domain (or business) model.

The main purpose of this model to see the forest from  the trees – understand the structure and deepest behavior of the chosen world. This model must (always) be created from scratch with the group of business people with best knowledge current business behavior and also the ideal ( or wanted) business behavior.

This work will take from such group 3 – 15 working days to finish. By then they have full understanding of the structure of their world and the most important business behavior with minimum amount of detail. This model has no application aspects what so ever! At this state most of the details are deadly poison for the modeling and the model.  The outcome (technically) is a class model typically 30 – 60 classes and their relationships (association, aggregation, inheritance etc.) and a few  (3 – 10) collaboration diagrams showing examples of  the most profound behavior  mechanisms of the domain.

This is a skeleton model and forms the bases for all application development around the model.

I am ready to facilitate the whole modeling phase. The modeling group must have basic knowledge on object-oriented paradigm and UML.

  • Training OOA and perhaps OOD

I have been giving Abstract Domain Modeling for more than 10 years time.

The training is conducted as one or two day training but the two day version with more exercises have proved to be better.   The amount of detail in Object Oriented Modeling is very limited. The whole content can be presented within two days. The first half day is theory starting from the meaning of modeling and the idea of OO paradigm. Then I will present the definitions and elements of OO and how these are used. Within this section I will also cover the UML notation. Then I introduce the student to abstract object-oriented domain modeling. In the afternoon the class is divided into exercises small group size 2 – 4 participants. These groups do the first exercise and then the results are worked trough together.  Next morning I will start with first day’s summery and then the groups will do the next more complicated exercise. Finally I will give an overview of application development starting from abstract domain model.

I have trained this way around thousand people both IT- professionals and business people. The evaluations of this training have been very good.

The size of an optimal class is from 9 to 16 student –preferably with homogenous background.

Then I have also given training to small amount of people on “pattern and techniques of OO modeling”. There are a small set of rules of thumb and best practices that gives vision of how to do the modeling. This is for junior modeling professionals with some working experience as a modeler. This is sort of a master class and can and should be tailored according to participants’ situation and skills. This training in total is 1 – 4 days.

  • I am willing to do this globally on-site as long as the working language is English (or Finnish).

Why Scrum needs desperately ADDD

(ADDD = Abstract Domain Driven Development)

OO- paradigm was actually developed to manage better complexity than previously had been achieved. The whole agile approach has the same idea.

Actually it reveals that the whole OO –development encourages doing things in agile way. Take for instance Grady Booch Object Solution it describes and recommends very pure agile approach even if the term agile was not yet used at that time in OO community.

The fundamental aim is to manage the complexity of the reality. The finding is that when the intrinsic complexity exceeds some threshold there is no way to do an overall design first and then implement it.

Here is a short quote from book by Schwaber & Beedle: Agile Software Development wit Scrum (page 24)

… They inspected the systems development processes that I brought them. I have rarely provided a group with so much laughter. They were amazed and appalled that my industry, systems development, was trying to do its work using a completely inappropriate process control model. They said systems development had so much complexity and unpredictability that it had to be managed by a process control model they referred to as “empirical.” They said this was nothing new, and all complex processes that weren’t completely understood required the empirical model. They helped me go through a book that is the Bible of industrial process control theory, Process Dynamics, Modeling and Control [Tunde] to understand why I was off track.

The agile solution is very simple: to manage complexity at the edge of implementation and narrow the degrees of freedom with implementing on the way. This is why it can be used in variety of disciplines. OO gives a description how this is done in the case of application development.

The nature of complexity in general is that it grows non-linearly. This means that when the number of components grows beyond a limit the complexity will explode.

The trouble with Scrum is that is very powerful tool to manage productivity of group of people. Because of it generality is doesn’t not offer anything software development specific.

The big question here is who to quickly find out the development direction with some accuracy. Starting from plain user stories lacks required direction and the experience is that heavy restructuring is needed in the 3. or 4. sprint, when the structure of the domain starts to emerge. Most of this is can actually be avoided when the effort is started with abstract modeling before the start of implementation (Scrum) project.

So the big question is, when we have to reduce the number of element how should this be done so that it still to retain the most significant aspects. My (modified) OO answer is the following:

  1. Abstract domain OO-model gives the simples model of required functional subset of reality
  2. To more simplify the task loosely connected aspects have to be kept very clean. This mean logical 3-tier architecture and middle tier business logic layer with no outside references what so ever.

These elements are tied together with iterative and incremental approach.

My modification separates the abstract domain (business logic) modeling right in the beginning and postpone the application analyzes much later in implementation phase.

So my recommendation to day is that an abstract OO domain model is always created prior Scrum development or as the first sprint. I prefer outside Scum, because the nature the work in this phase is not Scrum-like at all.  This is how I and my colleges have been working for years.

During the development phase the abstract model can (even should) be the basis for business tier implementation and the model should grow with number of attributes and methods. My experience is that increase in the number of classes needed for implementation is very minimal.


See also interesting discussion in LinkedIn :