Domain-Driven Design – What is it and how do

29
you use it?
Shares
April 21, 2017 (https://airbrake.io/blog/software-design/domain-driven-design) Andrew
Powell-Morse (https://airbrake.io/blog/author/andrewpomo) in Software Design
(https://airbrake.io/blog/category/software-design)
25 Expanding on our previous article that covered Object-Oriented Analysis and Design (https://air-
brake.io/blog/design-patterns/object-oriented-analysis-and-design) ( OOAD ), today’s article will ex-
plore domain-driven design ( DDD ). DDD is a software development approach that uses and
builds upon OOAD principles and ideas, so it’s the next logical topic for us to dive into.

Throughout this article we’ll examine what domain-driven design is, how it is commonly imple-
mented in modern development life cycles, and consider a few potential advantages and disad-
vantages of using DDD in your own projects. Let’s get crackin’!

3
What is the Domain?
To define domain-driven design we should first establish what we mean by domain in this con-
text (and in development in general). The common dictionary definition of domain is: “A sphere of
knowledge or activity.” Drilling down a bit from that, domain in the realm of software engineering
commonly refers to the subject area on which the application is intended to apply. In other words,
during application development, the domain is the “sphere of knowledge and activity around which
the application logic revolves.”

Another common term used during software development is the domain layer or domain
logic , which may be better known to many developers as the business logic . The business
logic of an application refers to the higher-level rules for how business objects (see: OOAD
(https://airbrake.io/blog/design-patterns/object-oriented-analysis-and-design)) interact with one an-
other to create and modify modelled data.

What is Domain-Driven Design?

Initially introduced and made popular by programmer Eric Evans in his 2004 book, Domain-Driven De-
sign: Tackling Complexity in the Heart of Software, domain-driven design is the expansion upon
and application of the domain concept, as it applies to the development of software. It aims to ease
the creation of complex applications by connecting the related pieces of the software into an ever-
evolving model. DDD focuses on three core principles:

◾ Focus on the core domain and domain logic .

◾ Base complex designs on models of the domain .
◾ Constantly collaborate with domain experts , in order to improve the application model and
resolve any emerging domain -related issues.

Evans’ Domain-Driven Design further defines a few common terms that are useful when describing and
discussing DDD practices:

◾ Context: The setting in which a word or statement appears that determines its meaning. State-
ments about a model can only be understood in a context.
 ◾ Model: A system of abstractions that describes selected aspects of a domain and can be used
to solve problems related to that domain .
◾ Ubiquitous Language: A language structured around the domain model and used by all
team members to connect all the activities of the team with the software.
◾ Bounded Context: A description of a boundary (typically a subsystem, or the work of a specific
team) within which a particular model is defined and applicable.

Building Blocks

Domain-driven design also defines a number of high-level concepts that can be used in conjunc-
tion with one another to create and modify domain models :

◾ Entity: An object that is identified by its consistent thread of continuity, as opposed to tradi-
tional objects , which are defined by their attributes .
◾ Value Object: An immutable (unchangeable) object that has attributes , but no dis-
29
Shares tinct identity.
◾ Domain Event: An object that is used to record a discrete event related to model activity within
the system. While all events within the system could be tracked, a domain event is only cre-
25
ated for event types which the domain experts care about.
◾ Aggregate: A cluster of entities and value objects with defined boundaries around
the group. Rather than allowing every single entity or value object to perform all ac-
tions on its own, the collective aggregate of items is assigned a singular aggregate root
item. Now, external objects no longer have direct access to every individual entity or value
object within the aggregate , but instead only have access to the single aggregate root
item, and use that to pass along instructions to the group as a whole. This practice correlates
with many of the actual coding practices we’re covering in our design patterns (https://air-
brake.io/blog/category/design-patterns) series.
◾ Service: Essentially, a service is an operation or form of business logic that doesn’t naturally
3
fit within the realm of objects . In other words, if some functionality must exist, but it cannot
be related to an entity or value object , it’s probably a service .
◾ Repositories: Not be confused with common version control repositories , the DDD
meaning of a repository is a service that uses a global interface to provide access to all
entities and value objects that are within a particular aggregate collection. Meth-
ods should be defined to allow for creation, modification, and deletion of objects within the
aggregate . However, by using this repository service to make data queries, the goal
is to remove such data query capabilities from within the business logic of object models .
◾ Factories: As we’ve discussed through a number of design patterns (https://air-
brake.io/blog/category/design-patterns) articles already, DDD suggests the use of a factory ,
which encapsulates the logic of creating complex objects and aggregates , ensuring that the
client has no knowledge of the inner-workings of object manipulation.

Domain-driven design also heavily emphasizes the ever-more-popular practice of continuous

integration , which asks the entire development team to use one shared code repository and push
commits to it daily (if not multiple times a day). An automatic process executes at the end of the work
day, which checks the integrity of the entire code base, running automated unit tests, regression tests,
and the like, to quickly detect any potential problems that may have been introduced in the latest
commits.

Advantages of Domain-Driven Design

◾ Eases Communication: With an early emphasis on establishing a common and ubiquitous
language related to the domain model of the project, teams will often find communication
throughout the entire development life cycle to be much easier. Typically, DDD will require less
technical jargon when discussing aspects of the application, since the ubiquitous language
established early on will likely define simpler terms to refer to those more technical aspects.
◾ Improves Flexibility: Since DDD is so heavily based around the concepts of object-
oriented analysis and design , nearly everything within the domain model will be
based on an object and will, therefore, be quite modular and encapsulated. This allows for vari-
ous components, or even the entire system as a whole, to be altered and improved on a regular,
continuous basis.
 ◾ Emphasizes Domain Over Interface: Since DDD is the practice of building around the con-
cepts of domain and what the domain experts within the project advise, DDD will often
produce applications that are accurately suited for and representative of the domain at hand,
as opposed to those applications which emphasize the UI/UX first and foremost. While an obvi-
ous balance is required, the focus on domain means that a DDD approach can produce a
product that resonates well with the audience associated with that domain .

Disadvantages of Domain-Driven Design

◾ Requires Robust Domain Expertise: Even with the most technically proficient minds working
on development, it’s all for naught if there isn’t at least one domain expert on the team that
knows the exact ins and outs of the subject area on which the application is intended to apply.
In some cases, domain-driven design may require the integration of one or more outside
team members who can act as domain experts throughout the development life cycle.
29 ◾ Encourages Iterative Practices: While many would consider this an advantage, it cannot be
Shares
denied that DDD practices strongly rely on constant iteration and continuous integration in or-
der to build a malleable project that can adjust itself when necessary. Some organizations may
25
have trouble with these practices, particularly if their past experience is largely tied to less-flexi-
ble development models, such as the waterfall model (https://airbrake.io/blog/sdlc/water-
fall-model) or the like.
◾ Ill-Suited for Highly Technical Projects: While DDD is great for applications where there is a
great deal of domain complexity (where business logic is rather complex and convolut-
ed), DDD is not very well-suited for applications that have marginal domain complexity, but
conversely have a great deal of technical complexity. Since DDD so heavily emphasizes the
need for (and importance of) domain experts to generate the proper ubiquitous
language and then domain model on which the project is based, a project that is incredibly
technically complex may be challenging for domain experts to grasp, causing problems
3
down the line, perhaps when technical requirements or limitations were not fully understood by
all members of the team.

Share this:

 (https://airbrake.io/blog/software-design/domain-driven-design?share=twitter&nb=1)

 (https://airbrake.io/blog/software-design/domain-driven-design?share=facebook&nb=1)25

 (https://airbrake.io/blog/software-design/domain-driven-design?share=google-plus-1&nb=1)

Related

Behavior-Driven Develop- Techniques for Preventing Conceptual Models - What

ment: What is it and how do Software Bugs (https://air- Are They and How Can You
you use it? (https://air- brake.io/blog/devops/tech- Use them? (https://air-
brake.io/blog/software-de- niques-for-preventing-soft- brake.io/blog/sdlc/concep-
sign/behavior-driven-devel- ware-bugs) tual-model)
opment) December 26, 2017 March 23, 2017
May 2, 2017 In "DevOps" In "SDLC"
In "Software Design"

Try Airbrake For Free (https://airbrake.io/account/new/free?utm_source=blog&utm_medium=footer

Latest From Our Blog Useful Links Contact Us

Airbrake adds SOC 2 Type II Airbrake Docs (/docs/) About (/about)  535 Mission Street, 14th floor,
Certification San Francisco, CA 94105
API Docs (/docs/api/) Contact (/contact)
(https://airbrake.io/blog/airbrake-
news/airbrake-adds-soc-2-type-ii- Blog (/blog) Jobs at Airbrake (/jobs)  1-888-479-8323
certification) Terms of Service (/terms)  [email protected]
 (/) As part of our continued Status Site Privacy Policy (/privacy)  facebook.com/airbrake.io
commitment to provide a the most
(http://status.airbrake.io)  @airbrake
secure platform to our customers,
we are pleased… Email Support
(mailto:[email protected])
Hotspots are heating up
(https://airbrake.io/blog/airbrake-
feature/hotspots-are-heating-up)
Helping users, it’s kinda the main
purpose we’re all building software
applications for right? I mean if a
digital…

Airbrake © 2019

29
Shares

25