by Prins Carl Santoso, Analyst at Mitrais

Breaking Complexity using Domain Driven Design

Information technology was first introduced in the late sixties. At that time the department of defence in the USA introduced the APARNET and ever since, our IT industry has advanced tremendously and has become crucial in many aspects of our daily life. 
One of them is business. Technology is regarded as an important tool within a company in terms of improving operations and functions, or it can be the very reason why a company exists. 
Company leaders continuously monitor most recent developments and updates of the technological industry in order to improve efficiency of the way organizations operate and also to be on the lookout of the transformational phase and come up with innovative strategies to drive growth.
Technology needs to be designed in accordance with business needs and goals. Therefore, this is a real challenge for us as a Software Development Company as we are asked to create Technology Solutions to help businesses within a very limited time frame. 
Domain modelling, as acknowledged by the software development community, is central to software design. Through domain modelling, software developers can express rich functionality and truly serve the needs of its users by translating functionality into software implementation. 
Despite its obvious importance, however, there are few practical resources that show how to incorporate effective domain modelling into the software development process. There are many things that make software development complex. The main problem in complexity is the essential intricacy of the problem domain itself.
The key to controlling complexity is a good model, a model that goes beyond a surface vision of a domain by introducing an underlying structure. With a model, we would think that visual and tactile learners would have a huge advantage because the model seems to mostly involve visual and tactile simulation. A good model which has a vision of a domain itself is acquired by applying Domain-Driven Design or DDD. This set of patterns was first codified by Eric Evans in the book Domain-Driven Design: Tackling Complexity in the Heart of Software. 
Domain-Driven Design is a set of tools or patterns that are used in designing and implementing the software that delivers high value, both strategically and tactically. By using DDD strategic development tools, you and your team will be able to create the competitively best software design choices and integration decisions for your business. In order to design a useful software, which accurately models the unique operations of the business, you can use DDD tactical development tools to assist you and your team. 
DDD is the most effective software design and implementation needed to succeed in today’s competitive business landscape. Complicated? Not Necessarily. However, it does involve a set of advanced techniques to be used on complex software projects. Domain-Driven Design will bring domain experts and software developers together to create a software solution that reflects the mental model of business experts. It is essential to have the same understanding of the business and provide a solution to help business processes. Therefore, the DDD method will need to invest in resources. 
Within our team, we have domain experts using the DDD. This way, the team will not only deliver the application but the true business value application. 
Let us go back to why DDD can help us to break complexity. I will discuss several items that DDD used to break complexity: 
First, let’s start with Ubiquitous Language. In DDD, we have a team collaboration between domain experts and software developers that bring together different points of views into one understanding. Ubiquitous Language is developed by the team, so they can have same understanding, and it usually works in bounded context. Ubiquitous language is rigorous-strict, exact, stringent and tight.  
Second is the Bounded Context. Bounded Context is a semantic contextual boundary. This is very important since within the boundary, each component of the software model has a specific meaning and does specific things. This is a transition from problem space to solution space. That is the area where a model is implemented and will have separate software artefacts for each of it.

Ubiqutous language in domain driven design  
After we have ubiquitous language and bounded context, both will be used as a foundation to create a Domain. Domain is something that an organization creates and usually, it has its own unique realm of know-how and way of doing things. This simply means, that when you want to develop a software for an organization, you are working in their Domain. Core Domain is the primarily value proposition of DDD and it usually addresses a major line of business.
These are three basic rules to use DDD in our design. Applying these correctly will help you acquire a valuable application design directly. If you believe that your application is complex, this will help you to break it into small pieces, then you can directly work on the specific task to build the application.
For example, if we want to create an online shop. How do we establish it? I believe there are many ways to create such application. First, we need to determine what to start with or what the customer instructs us to be done first.The next question is, do they have the same understanding with us for the part that we want to produce? In this matter, to avoid miscommunications DDD should be applied. 
To create an online shop, there are a lot of details to be considered. An online shop is a company or person that sells products online. However, there is no limit to what can be sold. Thus these products need to be categorized and organized. To do the business, a company must have a catalogue of products that they offer to the customers, and it must allow orders to be placed. Other than that it also needs to be able to collect payment for the sold product, and it must ship the product to the buyer. In this case, we already have 4 domain/subdomains: Product Catalogue, Orders, Invoicing, and Shipping.
That all seems quite enough to build the application. However, there is an additional detail which concerns inventory products and the forecasting. With all of the collected information, our design will look like this: 

Implementing domain driven design

Reference: Implementing Domain-Driven Design, Vaughn Vernon

From the design result above, you can just easily develop the application based on that design. Each domain will stand for themselves and when you integrate that, it will become one full application for an online shop. If you are using agile development methods, you can also discuss with your business experts which domain needs to be done first. Then you as software developers and them as business experts will have one understanding for each ubiquitous language that is already decided for each domain and bounded context.
Finally, there are so many models that we can use when we need to develop the application but with DDD, it is easier to understand the domain and we also have the same language inside the development. Business experts and software developers will have the same understanding of products and they will define the application thoroughly to support the business. When you have the business understanding, business model and also same language, it will help us to develop a valuable business application.