Professional Documents
Culture Documents
An Introduction To Domain Driven Design and Its Benefits - DZone Agile
An Introduction To Domain Driven Design and Its Benefits - DZone Agile
An Introduction To Domain Driven Design and Its Benefits - DZone Agile
[LIVE WEBINAR] Wednesday, June 10th: Getting Started with DevOps on Snowflake
Sign Up Now
DZone > Agile Zone > An Introduction to Domain Driven Design and Its Benefits
An application can be developed with an amazing architecture, using the latest technologies and have the
best interface, etc., but if it doesn’t solve the business’s needs, it won’t be considered useful. That’s where
domain driven design (DDD) comes in. As its name says, the point here is to focus on the domain of a
speci ic business.
In fact, to design good software, it’s important to know what that software is about. To create a banking
software system, you need to have a good understanding of what banking is all about, one must
understand the domain of banking.
DDD has a strategic value and it’s about mapping business domain concepts into software artifacts. It’s
about organizing code artifacts in alignment with business problems, using the same common, ubiquitous
language.
DDD isn’t a methodology, it’s more about the software’s architectural design, providing a structure of
practices to take design decisions that help in software projects that have complicated domains.
The DDD approach was introduced by Eric Evans in the book, Domain-Driven Design: Tackling Complexity
in the Heart of Software. Each developer here at Apiumhub has read it and we de initely recommend you
read it too!
DDD encompasses a common language, techniques, and patterns as well as an architecture. The focus is
put on the business and on modeling the problems that are trying to be solved.
With DDD, the developers get techniques that will help to minimize complexity and that will help drive
collaboration with the rest of the team. The idea is to use the requirements and to map out the business
processes into the model by using the same language that is used by the business itself.
Context
The context is a setting that determines the meaning of a statement.
Context Mapping
A graph that connects the contexts together. For each context, you ind a language, an independent
implementation, and an interface to talk to other bounded contexts.
Bounded Contexts
Bounded context is the context in which the ubiquitous language and the corresponding models are valid.
It gives the team a clear understanding of what has to be consistent and what can be developed
independently.
Model
The model is a system that describes the selected aspects of a domain and that is often used to solve
problems that are related to that particular domain.
Be loosely designed with no dependencies on the layers of the application on either side of the
domain layer.
Be an abstract and cleanly separated layer to create easier maintenance, testing, and versioning.
Designed with a “Plain Old Java Object” programming model without having any technology or
framework dependencies.
We do agree that this is a very brief and short introduction to DDD. The point of this article was to give you
an idea of what domain driven design is. I will leave you with a list of key bene its of DDD that might make
you even more curious about the topic!
Better Code
With DDD you end up with more readable code and less duplication.
Agility Is a Standard
By following an Agile approach that is iterative and incremental, DDD clari ies the mental model of
domain experts into a useful model for the business.
Communication Counts
Generally speaking, DDD comes in handy when it comes to helping the team creating a common model.
The teams from the business’ side and from the developer’s side can then use this model to communicate
about the business requirements, the data entities, and process models.
A Balanced Application
With DDD, you build around the concepts of the domain and around what the domain experts
are advising. This implies that the applications developed will indeed represent what the domain needs
instead of getting an application that is only focused on UX/UI, forgetting the rest of requirements. This
helps in creating a balanced product that suits the users/audience of that speci ic domain.
Purely Flexible
DDD turns around the concepts of object-oriented design. This implies that almost everything in the
domain model is based on an object and therefore will be modular and encapsulated, enabling the system
to be changed and improved regularly and continuously.
Published at DZone with permission of Lea Maya Karam . See the original article here.
Opinions expressed by DZone contributors are their own.
DZone > Agile Zone > Issue Prioritization Template
Introduction
Many companies have faced the problem of issue prioritization, and my team is no exception. Customers
wanted new features, managers offered their ideas, and developers came up with their solutions. Our
product backlog in Jira turned into an endless list of issues. The sprint planning meetings took hours and
ended up with the sprint still not getting the most signi icant backlog issues.
Our solution was to create a Google Sheets spreadsheet to prioritize tasks and synchronize the remote