Domain Driven Design and Model
IT Architect, Co-Owner of PerformIT
“Any fool can write code that a
computer can understand. Good
programmers write code that
humans can understand.“
Session Objectives and Agenda
• Introduction to Ontology.
• From the Ontology to Domain Driven
• DDD Building Blocks.
• Modeling Techniques.
• In philosophy ontology is the theory of
the nature of existence.
• In the context of information science it is
the study of entities and their relations.
• It is about modeling a domain of
knowledge by using high level of
• Learn and talk the language of the domain
• The language evolves with the domain model
and enables to describe the characteristics of
the domain with increased precision.
• Change in the language = change in the
model and vice versa.
• Knowledge crunching.
• Model is the backbone of Domain Driven
• Model forms ubiquitous language.
• Perfect tool for communication between
domain experts and developers.
• Explains complex domain in a simple way.
• Model and Code are bound.
• A Repository encapsulates domain objects
persistence and retrieval.
• Clean separation and one-way dependency
between the domain and data mapping
• Usually implemented with Object Relational
Mapping (ORM) techniques.
• May encapsulate different fetching strategies,
distributed caching, NoSQL and etc.
• Define an application's boundary.
• Services usually manipulate Entities
and Value Objects.
• A service typically implements a
business rule, generally something
that software must do.
• Each Aggregate has one Root Entity.
• The root identity is global, the identities
of entities inside are local.
• External objects may have references
only to root.
• Internal objects cannot be changed
outside the Aggregate.
• A program elements whose responsibility is
the creation of other objects.
• Create and manage complex domain
• Especially useful for creating aggregates
when atomicity is required.
• The model must reflect code changes and
• The amount of boilerplate code must be as
minimal as possible.
• The main focus is on the business domain
and not the infrastructure.
• Minimum friction with technology.
• Continuous integration, testing and
• As much automation as possible.
Code Generation Techniques
• NHibernate with NVelocity (.Net).
• Xtext with Xtend (Java, Eclipse).
• Protege (Java).
• Enterprise Architect (any language).
• MS Entity Framework (.Net) with T4.
• UML (any language).
• Spring Data (Java, Neo4J) and etc.
• Domain-Driven Design: Tackling
Complexity in the Heart of Software (by
• A Legal Case OWL Ontology with an
Instantiation of Popov v. Hayashi
Adam Wyner and Rinke Hoekstra,
Knowledge Engineering Review.