Introduction to Domain Driven Design

It's been more than 50 years before the software architecture was invented, but still project delayed and mismanagement cannot be solve. Some things inevitable because its a moving target, trust me that is the reality. It has been experience by all software engineer. In this article let me share you this software architecture approach.

Domain Driven Design (DDD) is an architectural pattern that will help succeed and to understand the software that we are building by modeling the classes based on the business requirements. Setting aside the technology that you must use and focusing on the problem domain is what you must do. Therefore, all you need is pen and paper. This design pattern are using strategic and tactical modeling tools to solve business problems.

DDD is not about technology. Instead, its all about understanding the problem space in the business domain.

To understand how the business works, you need to participate some discussion with your team to develop software discovery and knowledge crushing. Before we learn DDD, let us discuss first the overview of architectural layer.

Layered Architecture

Back then, there were only two layers: presentation and data. So, where is the business logic? Traditionally, business logic has been coded in the presentation layer (a.k.a user interface). This will make development faster - if you are a solo developer. Eventually, layered architecture emerged, dividing code responsibilities into four layers.

• Presentation Layer - There is only one job for this layer, and that is to display the data for the user.
• Application Layer - This layer is thin. It does not contain any business logic. The state of the task is in progress inside of this layer.
• Domain Layer - This is the heart of the software. All the business logic is inside here. The domain layer is persistent ignorance. The domain layer in DDD is purely a class object. Unlike other patterns, the database and entity are one such as MVC.
• Infrastructure Layer - You can imagine this as a supporting layer. It gives communication between other layers. One of the codes inside the infrastructure layer is an email sender.

The Three Pillars of Domain Driven Design

In order to understand the deep topic of this pattern, we need to be familiarize what actually DDD made up.

Ubiquitous language

In doing domain driven design, it is important the the software engineers and domain expert should work together. They are no vs us, there will be always us. The result of creating ubiquitous language will benefit all the people who are working in the software because both developers and client speak in the same language. Ubiquitous language is the language of business, therefore, the engineer who are working the system must understand the business.

For the mean time, let us consider that the bounded context is the a boundary around the system.

The customer inside the bounded context is a ubiquitous language. Therefore, customer has a different meaning in each boundaries.

Strategic Design

The main objective of this design is to identify the bounded context, ubiquitous language, and context map inside the system.

• Bounded Context - You can imagine this like a boundary of your ubiquitous language. For instance, the customer in delivery context and finance context has a different meaning. In finance context customer is the entity or the main entity of that context, while in delivery context the customer is only a value object of the order. If the discussion does not match in the customer scenario, it means you’re team is out of context. We will discuss deeply about entity and value objects later in this article.
  

• Context Maps - When you are done creating a two or more bounded context, there is a relationship between those boundary. Context mapping is way to model and to connect by visualizing the relationship of those context.

Tactical Design

This design is used when you create your domain model inside of your bounded context. The building blocks are entities, value objects, aggregates, services, and repositories. I will explain only the overview of those building blocks in this article.

• Entities - it is a class that has identity and it remains the same thought out your system.
• Value Objects- it is also a class but unlike entities it has no identity. Value objects are being used by the entities to represent the attribute such as age, address, and so on. The attribute is validated inside the value object class.
• Services - every layer has a service. For instance, one of the services inside the application, it is called the application service. The purpose of application service is to handle the flow of use cases in the system.
• Repositories - If you are a software engineer, you have heard this already and probably you have an idea of what it is. Repositories are an abstraction of your database (SQL code). You named the abstraction based on the language that the business uses such as getAllSingleStatusUsers() just like that.

Conclusion:

In software development, there are no single solution in every problem. If you have a small application or the requirements is only basic CRUD functions, I think you don't need a DDD. It all depends in the application that your are building. You can try this DDD architecture design if your application will grow and has many functions. I hope you finally understand the basic concept of DDD. In my next article let us discuss deeply about entities and value objects with some sample codes.

What kind of architectural pattern you are using now? Are you facing some challenges when the application grows? Let me know in the comment and don't forget to share this article. Thanks for reading. (-: