Domain Driven Design and Model
Driven Development
Geyzersky Dmitry
IT Architect, Co-Owner of PerformIT
dima@performit.co.il
http://www.performit.co.il

“Any fool can write code that a
computer can understand. Good
programmers write code that
humans can understand.“
Martin Fowler

Session Objectives and Agenda
• Introduction to Ontology.
• From the Ontology to Domain Driven
Design.
• DDD Building Blocks.
• Modeling Techniques.

Ontology
• 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
abstraction.

Ontology and Semantic Technologies

Domain Driven Design
• Model driven software design approach
used to tackle complexity of software
projects.
• DDD focuses on the domain
logic.
• The term was coined by
Eric Evans in his book.

“Strategy is doing the right things,
tactics is doing things right.“
Peter Ferdinand Drucker

Ubiquitous Language
• Learn and talk the language of the domain
experts.
• 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.

Creating Ubiquitous Language

Domain Model
• Model is the backbone of Domain Driven
Design.
• 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.

Layering

DDD Building Blocks
Domain Model

Entities
Objects having a unique identity throughout
the states of the software.

Entities
We compare entities by their IDs.

Value Objects
• Objects describing certain aspects of the
domain which don’t have identity and
lifecycle.
• Immutable - if you need to change the
object, just create a new one.

Value Objects
• We compare Value Types by comparing their
properties one-by-one.

Repositories
• A Repository encapsulates domain objects
persistence and retrieval.
• Clean separation and one-way dependency
between the domain and data mapping
layers.
• Usually implemented with Object Relational
Mapping (ORM) techniques.
• May encapsulate different fetching strategies,
distributed caching, NoSQL and etc.

Services
• 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.

Aggregates
• 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.

Factories
• A program elements whose responsibility is
the creation of other objects.
• Create and manage complex domain
objects.
• Especially useful for creating aggregates
when atomicity is required.

Domain Events
Represent the states of Entities

DDD Challenges
• The model must reflect code changes and
vice versa.
• 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
refactory.
• 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.

References
• Domain-Driven Design: Tackling
Complexity in the Heart of Software (by
Eric Evans).
• http://nhforge.org/blogs/nhibernate.
• http://www.springsource.org/spring-data.
• http://www.eclipse.org/xtend/.
• A Legal Case OWL Ontology with an
Instantiation of Popov v. Hayashi
Adam Wyner and Rinke Hoekstra,
Knowledge Engineering Review.

For more information:
dima@performit.co.il
or
http://www.performit.co.il