Domain Drive Design: A Very Short Introduction for Business People, prepared by Emre Sevinç, Co-founder & CTO of TM Data ICT Solutions. This is a high level overview that might help guide the discussions to explore if Domain Driven Design (DDD) is good fit for different industries and their complex software and data projects.

1. A Very Short Introduction to
Domain Driven Design (DDD)
Emre Sevinç
23-Sep-2020
http://tmdata.be

2. Domain Driven Design: The Message | 1
“First, we want to establish the idea that a computer
language is not just a way of getting a computer to
perform operations but rather that it is a novel formal
medium for expressing ideas about methodology. Thus,
programs must be written for people to read,and only
incidentally for machines to execute.”

3. Domain Driven Design: The Message | 2
“The purpose of abstraction is not to be vague, but
to create a new semantic level in which one can
be absolutely precise.”
Edsger W. Dijkstra (1930 - 2002)
Dutch computer scientist, software engineer, and pioneer

4. Domain Driven Design: The Reality
When building automation & software systems for your business, do you find yourself...
● trying to translate/map between your business terms and ICT & software jargon?
● looking at a piece of software code, hitting semantic barriers, and scratching your
head?
● wishing for an “utopia” where designers, engineers, and programmers could speak and
write in the “same language”, even down to the software code level, at least for a
part of the complex business domain?

5. Domain Driven Design: Language vs Language
Imagine a group of doctors, nurses, and software developers discussing a system related to the
tracking and recording of giving vaccine shots to the patients. Which software version would you prefer if
you were a doctor or a nurse?*
Possible Viewpoint Resulting Code
“Who cares? Just code it up!” user.setAction(actions.ShotTypes.TYPE_FLU);
user.setProperty(dose);
user.setOperator(nurse);
user.runAction();
“We give flu shots to patients.” patient.giveFluShot();
“Nurses administer flu vaccines to
patients in standard doses.”
vaccine = vaccines.standardAdultFluDose();
nurse.administerFluVaccine(patient, vaccine);
*
Adapted from Vernon (2013)

6. Domain Driven Design: What?
● Put domain experts and software developers on the same page
○ build software intensive systems that make perfect sense not only to the
software developers, but also to engineers and managers from the business.
● Teach the business more about itself.
○ Not every domain expert or C-level manager knows every part of the domain.
DDD lets everyone to contribute.
● Go beyond “tribal knowledge” locked in separate software systems: centralize the
knowledge, make it explicit, make it in the language of the business people and
engineers.
● Zero translations between the domain experts, software engineers, and the actual
software source code. Because the team develops a common, shared language, and
uses this not only in meetings, but also in actual software.

7. Domain Driven Design: Major Concepts & Patterns
● Domains
● Subdomains
● Bounded Contexts
● Ubiquitous Language
● Context Maps
● Architecture
● Entities
● Value Objects
● Services
● Domain Events
● Modules
● Aggregates
● Event Sourcing
● Repositories
Strategic Tactical
Programmers love to
talk about these.
Can you guess why?

8. Domain Driven Design: Why?
The major benefits of the Domain Driven Design style are:
● Communication: All members in a software development team can use the domain model
and the entities it defines to communicate business knowledge and requirements using
a common business domain language, without requiring software jargon.
● Extensible: The domain model is often modular and flexible, making it easy to update
and extend as conditions and requirements change.
● Testable: The domain model objects are loosely coupled and cohesive, allowing them to be
more easily tested. When done really well, even business stakeholders can easily write tests in
Behaviour Driven Development (BDD) style.

9. Domain Driven Design: Business Value
● The business gains a useful model of its domain: a refined, precise definition and
understanding of the business is developed.
● Domain experts contribute to the software design.
● A better User eXperience (UX) is gained.
● Enterprise architecture is better organized.
● Agile, iterative, continuous modeling is used.

10. Domain Driven Design: Yes or No?
● Consider DDD if you have a complex domain and you wish to improve communication and
understanding within your software development team, or where you must express the
design of an application in a common language that all stakeholders can easily
understand.
● DDD can also be an ideal approach if you have large and complex enterprise data scenarios
that are difficult to manage using other techniques.
● Be careful! In order to help maintain the model as a pure and helpful language construct, you
must typically implement a great deal of isolation and encapsulation within the domain model.
Consequently, a system based on DDD can come at a relatively high initial cost. While DDD
provides many technical benefits, such as maintainability, it should be applied only to
complex domains where the model and the linguistic processes provide clear benefits in
the communication of complex information, and in the formulation of a common understanding
of the domain.

11. Domain Driven Design
Thanks for Thinking Together!
Questions?

12. Domain Driven Design: Resources
● “Domain-Driven Design: Tackling Complexity in the Heart of Software”, 2003, Eric Evans
(Addison-Wesley)
● “Applying Domain-Driven Design and Patterns", 2006, Jimmy Nilsson (Addison-Wesley)
● “Domain Driven Design Quickly”, 2006, Floyd Marinescu, Abel Avram
● “Microsoft Application Architecture Guide, 2nd Edition”, 2009, Microsoft Patterns & Practices
Team
● “Implementing Domain-Driven Design”, 2013, Vaughn Vernon (Addison-Wesley)
● “A Philosophy of Software Design”, 2018, John Ousterhout (Yaknyam Press)