26
Domain Driven Design and Model Driven Development Geyzersky Dmitry IT Architect, Co-Owner of PerformIT [email protected] http://www.performit.co.il

Domain driven design and model driven development

Embed Size (px)

DESCRIPTION

The presentation I gave at Iltam (Herzelia, Daniel Hotel) on 23.05.2012

Citation preview

Page 1: Domain driven design and model driven development

Domain Driven Design and Model Driven Development

Geyzersky Dmitry

IT Architect, Co-Owner of PerformIT

[email protected]

http://www.performit.co.il

Page 2: Domain driven design and model driven development

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

Martin Fowler

Page 3: Domain driven design and model driven development

Session Objectives and Agenda

• Introduction to Ontology.

• From the Ontology to Domain Driven Design.

• DDD Building Blocks.

• Modeling Techniques.

Page 4: Domain driven design and model driven development

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.

Page 5: Domain driven design and model driven development
Page 6: Domain driven design and model driven development

Ontology and Semantic Technologies

Page 7: Domain driven design and model driven development

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.

Page 8: Domain driven design and model driven development

“Strategy is doing the right things, tactics is doing things right.“

Peter Ferdinand Drucker

Page 9: Domain driven design and model driven development

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.

Page 10: Domain driven design and model driven development

Creating Ubiquitous Language

Page 11: Domain driven design and model driven development

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.

Page 13: Domain driven design and model driven development

DDD Building Blocks

Domain Model

Page 14: Domain driven design and model driven development

Entities

Objects having a unique identity throughout

the states of the software.

Page 15: Domain driven design and model driven development

Entities

We compare entities by their IDs.

Page 16: Domain driven design and model driven development

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.

Page 17: Domain driven design and model driven development

Value Objects

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

Page 18: Domain driven design and model driven development

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.

Page 19: Domain driven design and model driven development

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.

Page 20: Domain driven design and model driven development

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.

Page 21: Domain driven design and model driven development

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.

Page 22: Domain driven design and model driven development

Domain Events

Represent the states of Entities

Page 23: Domain driven design and model driven development

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.

Page 24: Domain driven design and model driven development

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.

Page 25: Domain driven design and model driven development

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.

Page 26: Domain driven design and model driven development

For more information: [email protected]

or http://www.performit.co.il