Such a decision may lead to fall in an application’s popularity, or in the worst case scenario, it may lead to a company going bankrupt. Case in point, the history of Opera at one time they decided to rewrite the software. Opera as a company is still an important player in the browser industry, but it is not as strong as it was years ago. In the history of IT history we’ve seen companies that decided to rewrite software from scratch as Opera’s did , but the world isn’t aware of such failures.

Software is for a Business.

The Internet is full of pages, guides, tutorials, movies, and others which depict how to build software using DDD – Domain Driven Design. Only a fraction of them point out that DDD isn’t a paradigm (or framework nor methodology) of software development. It is a more or less comprehensive approach, starting from the process of gathering a client’s (or domain expert’s) requirements, through to  a precise understanding of what the software is supposed to do (this is achieved through Event Storming sessions, the Big Picture one, and followings), leading to architectural design of the software itself, just to prevent our software from ending up in the identical situation as Opera.

A basic principle of DDD is that software should be useful for business. Hence, whatever business guys (or client) wants, has to be delivered (although, it has to be remembered, that sometimes it is not possible to achieve this what is requested). Using a classic approach to software development, a developer receives documentation and starts implementation. The funniest part for such person is to build the whole infrastructure, base classes and sophisticated technological solutions which will grant the possibility to proudly say “look upon the genius solution I’ve created, I am so proud”.

I precisely know how this works as I am a software engineer and I love to dig deep into the technical stuff while figuring out the best possible solutions for the problems I have to deal with. Because of the love we have for the technical stuff, we are able to forget about… the business itself. After some time, it appears that our super-duper code which we were proud of only a few weeks earlier – does not satisfy the business guys and delays finishing an application. But wait, our code is so cool, that we can’t simply remove it and replace with something else as we spent so much time creating it. Beside that, it is so deep in the application, that it is not possible to do this within a reasonable time.

D like Design

Why do we create software? To provide value to the customer, and this is main concern of  DDD’s. Against what many developers say, the last “D” in this acronym doesn’t mean “development” but “design”. As you can see, the burden is shifted from the development phase to design phase. With good implementation of Domain Driven Design, the source code of an application is a side effect, not the aim itself. The goal is to provide value to business (client) throughout mutual understanding of the requirements.

How to achieve that? The first and most important is a full understanding between the business guys (client) and the technical staff. It is quite common that business guys understands one thing, while technical people understand it in a different manner. In DDD you acknowledge that language is ubiquitous – and that is a fact. It is critical to understand each other on language level and context, and to use appropriate words depending on the context. As an example we can work on a term “user”.

If we consider a “user” in case of system account, it can be defined as “person, who has a first name, surname, username and password”. Will a “user” be described exactly the same when we considered  in different cases? For instance in the context of company’s financial department? Probably not. In this context, the description would rather be like “a person who has an identification number, financial account number, list of received and sent invoices, list of payments received and sent”. At a glance, it can be seen that in different cases, the same term may have a totally different meaning. And here is where DDD comes into play.

Ubiquitous language

According to the basic DDD foundation, at each meeting common (ubiquitous) language is established or continued from previous meetings and  it is critical to have this common language established. Because of that, when there is a meeting related to new functionalities for instance for the financial department when business guys talks about a “user”, everyone knows its precise description and will not confuse it with a “user” in a system account sense. To avoid confusion it is a must to use common terms settled with business guys or a client when an application is written by developers – in the source code, exactly the same names, and descriptions as we started to use at meetings, has to be used within it. Doing so we avoid discrepancies with what business guys requested and what is developed in an application. Such differences may lead to further issues with our software and to the decision – we have to rewrite our code – and this is something we should avoid at any cost. Maintaining consistency of wording ease finding proper source code pieces and it eases each meeting as everyone understands exactly what other states since everyone uses the same language.

When everyone understands that language is a critical part of the whole process, the rest of the process moves forward  smoothly. In the case of a standard driven project, meetings occur quite often. These meetings might be refinements (or groomings) or any other meetings with more detailed information related to the project. They may be a result of requirements change or discovery of something that should change them. It is similar when you use DDD – meetings should be scheduled whenever they are needed, just to resolve issues when they happen, at a very early stage. At these meetings, we set common language we use across the whole project since this the most important part of the whole process of software development. When everything will work like a Swiss watch, using conception presented by Eric Evans, the source code almost writes itself and is consistent with the requirements.

In case of DDD, meetings are not only for gathering information about client’s requests. It is more a constant discussion leading to resolving all discrepancies. Applications designed in this manner are driven is such way, that even not technical people are able to understand fully the whole process and are active participants. Such meetings are called Event Storming sessions.

How to meet

Let’s imagine there is a project, there were few meetings describing requirements and so on. Suddenly it was realised that something is missing – quite normal, such situations happens everywhere all the time. Your manager / domain expert (for instance chief accountant, when financial stuff is on the table) is a very busy person. It is virtually impossible (and not professional) to meet with such person every single day for half an hour because we have found something missing in our documentation. When you organize Event Storming session such issues happens rarely. When a domain expert (person who knows a lot about certain topic/domain from business perspective) finds time, we have to use it as much as we can get get answers to all possible questions. Even questions that now are not relevant, but may be in the future.

To drive this meeting in a most proficient way, we need as follows:

1. Domain expert or experts (business/client/someone who knows the topic from business viewpoint) and the technical team
2. Paper roll with 1m width (~3.3 ft) and length of 10m (~33ft)
3. Coloured sticky notes (needed colors: orange, lightblue, violet, pink, yellow)
4. Pens or markers

It is quite obvious that the meeting will be conducted with both interested sides, so the description of point 1 can be omitted. It becomes interesting when we get to the second point where paper roll with certain dimensions is pointed out. Why do we need this? If we look into points 3 and 4, we can figure out this is needed to stick our notes to it, and only for this reason. Paper roll is used because of 2 things. The first one is because sticky notes adhere better to paper than a wall or a board and stay there for longer. The second one is because unrolled paper can be rolled back and easily moved to another place.

Two types of meetings can be distinguished – the first one is Big Picture, where basic idea of project or application is described. As a result of this meeting, raw project idea is spread across the technical team and the basic requirements are described. After this meeting (or meetings, because sometimes one is not enough to draw the Big Picture) people know what is happening in the project and its domains (a domain is logical piece of business, which is independent of other, mostly the “domain” term is strictly tied to company’s departments – financial department, HR department, IT department, and so on).

After the Big Picture has been drawn up, it is time to get to the details. Now, Event Storming sessions are more about what is going on in each domain or context (context is smaller piece of domain, like team in each department or people involved into these teams). Apart of this, these meetings are more or less the same as Big Picture meetings, and from this point we use our paper roll and sticky notes extensively.

To have the possibility to describe how Event Storming meeting looks like, I have to describe sticky notes colours and what should be written on them.

Sticky notes colours and their meaning:

1. Orange – event. On such piece of paper we have to write events that happened in our application. For instance “user registered”, “invoice issued”, “invoice paid” and others. Here we always  have to use the past tense, as an event (to be precise information about an event) always happens after the event has happened. On this stage everything is written in natural language as non technical persons are present and ubiquitous language has to be used. Every person involved writes events on a piece of paper and sticks them to the unrolled paper. The unrolled paper should be taped to the wall, so every person in the room has easy access to it. At the early stages of our Event Storming sessions we should concentrate on events happening in our application. When we decide there is enough of them (it will happen probably when no one will adhere any new sticky note to our unrolled paper) and we see what is happening in the software, we are allowed to move forward.
2. Blue – decision / action. Here we state which command invoked generates events from point 1 (written on an orange sticky note). On the time axis they are placed on the left side of events. From this point we can segregate events with appropriate decision / action cards.
3. Yellow – user / aggregate root. Describes the  command invoked from point 2. It is placed on the left side of a blue sticky note. If a user invokes – the card is yellow. If an aggregate root (in DDD is a part of code that is a root for all actions more or less) – colour can be light yellow.
4. Violet – puzzle. Here are written all things that should be resolved later. All unanswered questions, technical issues seen at this stage, information to get and so on. For instance, at the moment we don’t know how an external, banking system works, so it has to be resolved later.
5. Pink – an external system. If we have to connect to PayPal, ebay or whatever, we should write it on a pink sticky note.

After enough a number of sticky notes have been written and adhered to the unrolled paper, and when we see what is happening in the project or system, when we know who or what invokes commands and related events, it is time to group some related flows into something called bounded contexts after which we can move these groups on the time axis. Remember that domain is something that we can compare to a company’s department, and bounded context is something we can compare to a team that is responsible for actions mentioned prior.

Core Domain

During our grouping process we can, and we should to be honest, isolate something called Core Domain, where this term describes which parts of the system are the most valuable and important to the organization. Client or business guys describes which parts of the system can be included into this. Everything else that isn’t part of the Core domain, is included into sub-domains, where they have a role of supporting domains. For example the postal department in an IT company will not be included into the Core domain. It is only a support department, while the most valuable part of business is done in other parts of the organisation.

When this part is done and the Core domain is set, the appearance of business guys / client isn’t required further. However, we have to remember that software is created for them, by meeting them frequently, better software is created. Nonetheless, they are usually very busy, and can’t spend every minute with the technical team. That’s why a good roadmap is so important. As a consequence of such a good roadmap, the source code is reflection of it, and that’s why it is so important to drive whole process in the right way, whereas the source code is then the side effect of this.

An Event Storming session should last from a few minutes to a couple of hours, nonetheless there are no limitations When people involved get to the point where they can’t think up about any new sticky note they would like to adhere to our working sheet, that’s the moment, where a break till next day is needed. The next day it may turn out that some pieces we had already put on the wall are unnecessary, whilst we forgot about others. When we get enough information, it is time to the funnies (for developers at least) part of the work – implementation. Remember – with the whole process driven in the right manner, the source code is a reflection of our unrolled paper sheet with sticky notes adhered. For instance “user sends registration form” -> “user registration process” -> “user registered event” and this may be translated to such classes in the code: UserSendsRegistartionFormCommand -> UserRegistrationFormCommandHandler -> UserRegisteredEvent.

Big Ball of Mud

Domain Driven Design isn’t something new in the IT world, although it is neglected in many companies. Plenty of people are unaware that  something like that even exists. Others know, however, think it is not needed in their cases. The truth is that companies (and people) can be divided into two groups – those who knows DDD and use it when applicable and those who sooner or later will use DDD in their software development processes.

It is linearly correlated to the growth of the application. Even the smallest one, after some time and after some company economical growth, grow. New business logic is added, new functionalities appear. If we don’t handle this properly at certain point in time, we may end up with something called spaghetti code – where everything is connected with everything and even the smallest changes create headaches for employees. In DDD such spaghetti code is called Big Ball of Mud.

Obviously, DDD isn’t the best method of software design for every single case. For instance, if an application (or its module) should handle only CRUD operations (Create, Read, Update, and Delete operations), there is no point then to use DDD. The reason is that extra time and extra lines of code will be needed just to fulfill Domain Driven Design needs, it will never pay off. This way of design and work is what you need when business logic is complex or we know it will be such in the future. In case of something being very clear, there is a point of using this approach as it would be like using a sledgehammer to crack a nut.

The article originally was written and posted on https://geek.justjoin.it/od-kolorowych-karteczek-po-implementacje-kodu-autostopem-przez-domain-driven-design/ in Polish, later translated by Author (so, this is me) and published on my portfolio’s blog, so this is where you are now 🙂