Domain driven design being the tailor in the mass production era
16 Mar 2018Developmentsoftware architecture
The Domain Driven Design
The first principle of the concept is the domain, as the most important layer of the project, not the technology or business KPIs. The domain is a sphere of knowledge or the matter. That will make the use of the software that is to be produced.
Based on that knowledge, the team constructs the model of the software. The models are designed to solve the problems and overcome the challenges of the company.
In the core of the concept lies a forging of an uneasy alliance between the technical experts. Basically, the developers. Next is the domain experts. In practice, the people with expertise and knowledge of the domain the software is going to work for. As the effect of the collaboration, there comes the model, that genuinely represents the business need of the client. In fact it was co-produced with the client.
As the concept sounds simple, it’s different compared to the conventional model of seeking “the best solution available”. Setting up some twists and modifications later. It may resemble buying clothes. There are plenty of shops that sell unified sizes and massively produced garments. But yet only a professional tailor, who take a measure of his customer can prepare the best fitting suit.
The unique value of Domain Driven Design comes in seeing the whole project as one with a unified model. This approach makes the software more bugproof and useful for the end users. As long as there are no “unexpected obstacles” caused by the lack of communication or knowledge either on the business or the technological side.
The things that we need
As the concept of Domain Driven Design is quite simple, it is not that easy to start working in that way. First of all, at least part of the dev team has to be experienced in this way of working. It is neither easy nor fast to bound the perfect communication with the domain experts. And it requires soft skills and experience.
What’s more, the technical team has to be determined and focused on gaining a real understanding of the customer’s business. And in fact, there is much more than seen at first glance. All the software objects, the database structure and the code itself has to be fitted into the business model and logic of the customer. The team cannot lose the context of the implementation.
Without the proper mapping the client’s organization onto the model, there is no Domain Driven Design. Last, but not least, there is a need for some stubbornness in the team. It is tempting to simplify or ignore some minor issues. There is a great potential of the butterfly effect in programming, and any overlooked problem or challenge may result in some more significant disturbance in the future.
Why Domain Driven Design?
As the domain driven design is neither simple not fast, it comes with really significant advantages that are not to ignore easily. First of all, the system better suited to business is much easier to modify. Why is that so? There are no artificial obstacles created during the design process as an effect of misunderstanding between the programmers and the business people.
That makes the process of adding new functionalities much more comfortable, as the implementing designing the new products come easy for the business that the software is prepared for. That makes the system’s aging easier to handle. If the software is suited in the best way possible to the business, there is a much bigger chance, that it will be used for the much longer time with better effect.
“Most of the problems with IT comes when the technology team does not fully understand the needs and contexts of the realissues their software will be solving.”
And last but not least, the holistic approach to the design process makes the analysis of the business processes much more manageable. That’s the first step into the big data world, where the bigger picture may be seen and further optimization was done. In fact, the Domain Driven Design is the pinnacle of the digitalization of the business processes.
All those synergies would be useless without the micro-editions, which make the upgrading and applying the modifications much easier.
Summary of DDD
The Domain Driven Design is a challenging yet rewarding way to design business class software. It is a grand illusion that there is ERP or CRM version of “one size fits them all”. Every business has it’s unique challenges, values and business advantages. With a deep understanding of the process, the technology team may create outstanding software to support business processes.
Yet, the aforementioned deep understanding of the client’s business and bounds with the non-technological experts are even more rewarding and valuable, as the knowledge and experience is the most precious thing the one can ever get.
Sebastian is a true observer, good at reading people. He is a focused perfectionist, who loves delving into areas like bible study and team development.