Delivery
4 min
Moving from agility to antifragility in IT l Adservio
View more
November 20, 2023
.jpg)
Success Story
3 min
BNP Paribas: Bringing IA to financial regulation
View more
June 8, 2021
We often consider domain-driven design when building resilient digital experiences for our clients. But what exactly is this concept? How does it work? How does it impact software development?
Let us learn what DDD is about and how can organizations benefit from using its concepts.
Domain-driven design might sound like a new concept, but it's been around for nearly 20 years.
Programmer Eric Evans introduced the idea in his 2003 book, "Domain-Driven Design: Tackling Complexity in the Heart of Software"—one of the most significant titles in the history of software development, in our humble opinion.
Since Eric's book, communities of software engineers and developers have built on the principles of domain-driven design to solve the problem of complex domains, which can complicate development workflows.
Before we explain the domain-driven design quickly, it's important to understand the meaning of domain logic (also called business logic).
In a software engineering and development context, 'domain logic' refers to the software principles that influence business-critical decisions.
In his book, Eric Evans talks about how software should fulfill the business needs of the end users that invest in that software.
You should also be aware of domain modeling, which shows the relationships between concepts and entities that solve business problems. It helps developers deal with domain logic.
Keep domain logic and domain models at the front of your mind when learning about domain-driven design.
Domain-driven design—or DDD, for short—is an approach to software development that solves real-world business problems through code.
Here's a quick example:
Domain-driven design categorizes microservices—another software development approach where business applications work together but also independently from one another—so end-users can better understand those microservices.
The primary goal of design-driven design is to standardize language, strategies, workflows, and design patterns when developing an application.
The focus is on the business using the application, not the application itself.
That differs from other software and product development approaches that might minimize development complexity but ultimately concentrate on how a software tool functions in different contexts.
Domain-driven design is a software development approach that suits complex applications requiring multiple workflows.
This approach might benefit your organization if you want to align development with your long-term business goals and end-user requirements.
Domain-driven design can also improve design maintenance. That's because it has a layered architecture that makes it easy to change and upgrade applications during and after the development process (more on this later).
There are two approaches to domain-driven design:
Tactical design refers to the different components (building blocks) used to create a domain model. These components need to work in a specific context for domain modeling to be successful.
Entities execute business logic within a domain model and have a unique identifier.
Value objects are like entities but don't have a unique identifier. They can make it easier to create complicated calculations in a domain model. Developers can also use them to isolate logic from entities.
An aggregate is a cluster of entities and value objects within a transaction boundary—where a transaction in microservices starts or rolls back. An aggregate root is the parent entity of the cluster of entities and value objects.
Factories control the beginning of the aggregate lifecycle. They create aggregates and can return an aggregate, entity, or value object.
Repositories control the middle and the end of the aggregate lifecycle. They persist in aggregates and solve problems with data storage.
A service is a stateless class between entities and value objects but is not connected to either.
Aggregates can publish events that happen in the core domain. Developers can use events to track changes to the state of an application.
The Strategic design model organizes design around context instead of functions. We can break the strategic design into three components:
As previously mentioned, this is an object-oriented way to deal with domain logic. Domain models can solve business problems and improve application development.
This is the language that everyone involved in domain-driven design (business team members, development teams, domain experts, etc.) understands.
When different teams use different languages, it can influence application behavior and software architecture, resulting in longer development times and software vulnerabilities.
Bounded context refers to the boundary within a domain where teams can define and implement a domain model.
These contexts are not always isolated from each other.
Domain-driven design is important for many reasons:
Domain-driven design isn't something that most businesses can do themselves. It requires advanced domain expertise and knowledge of domain models and logic.
Working with a company that delivers world-class software engineering and development can help your organizations create applications that solve real-world business needs.
Domain-driven design is a software development concept about designing applications for business value.
There are two approaches to domain-driven design, and understanding the principles of each can encourage developers to create software that influences business-critical decisions.
While this design concept requires advanced domain expertise, it can improve communication, reduce domain complexities, and focuses on end-users.
Adservio works with organizations in assisting them in implementing a domain-driven approach, improving software delivery, and streamlining operations toward better solving the needs of end-users.
.png){kind=logo}
