Understanding Domain Driven Design (DDD)

It's been more than 50 years since software architecture, as a concept, was invented, but still, project delays and mismanagement still plague the industry. Some things are inevitable because the software ecosystem is a constantly moving target, trust me that is the reality. It’s something that every software engineer has experienced. In this article, I’ll share a different approach to navigating software architectures.

Domain Driven Design (DDD) is an architectural pattern that helps us understand the software that we are building by modeling the classes based on business requirements. Setting aside the technology that you must use and focusing on the problem domain is what this approach is all about. This design pattern are using strategic and tactical modeling tools to solve business problems.

To start, all you need is a pen and paper.

DDD is not about technology. Instead, its all about understanding the problem you’re to solve in a business context.

To understand how the business works, you need to participate in some discussions with your team. This gives you an in-depth understanding of business goals and allows you to carry out software discovery efficiently. Before learning exactly what DDD is, let us discuss layered architecture.

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 ideally makes 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 this layer.
• Domain Layer - This is the heart of the software. It contains all the business logic. The domain layer is persistent ignorance.
• Infrastructure Layer - You can think of this as a supporting layer. It fosters communication between other layers.

The Three Pillars of Domain-Driven Design

In order to understand DDD, we need to be familiar with what actually makes it up.

Ubiquitous language

In domain-driven design, it is vital for software engineers and domain experts to work together. There is no this team vs that team, it’s all one big team.

Creating ubiquitous language will benefit all the people working on the software because both developers and clients speak the same language. Ubiquitous language is the language of business, therefore, the engineer who is working the system must understand the business.

In the meantime, let us consider that the bounded context is a boundary around the system.

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

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 think of this as a boundary for your ubiquitous language. For instance, the customers in a delivery context and finance context have different meanings. In a finance context, the customer is the entity or the main entity of that context, while in a delivery context, the customer is only a value object of the order. If the discussion does not match the customer scenario, it means your team is out of context.

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

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.

• Entities - it is a class that has an 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 used by entities to represent attributes 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, is called the application service. The purpose of the 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 you probably 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().

Conclusion

In software development, there is no single solution to every problem. If you have a small application or the requirements are only essential CRUD functions, I don’t think you need DDD. It all depends on the application that you are building. You can try DDD architecture design if your application grows and has many functions.

I hope you finally understand the basic concept of DDD. In my next article, entities and value objects with some sample codes.

What kind of architectural pattern are you currently using? Are you facing challenges as you scale? Let me know in the comments and don't forget to share this article.

Thanks for reading. (-:

Also published here.