DDD An introduction to Domain-Driven Design 

Speaker at Software Architect and Developer on large object-oriented business applications. Currently I’m particularly interested in agile software development, Domain-Driven Design, CQRS and NoSQL databases. Software Architect at 

Why are we here? 

We want to know the secret ingredient to write a good software! 

What does writing good softwares mean? • No bugs? • Sometimes, even a bug could be a good thing :-) http://www.forbes.com/sites/grantmartin/2013/09/12/error-in-booking- engine-puts-united-airlines-tickets-at-0/ 

Why software sucks • This doesn’t do what I need • I can’t figure out how to do what I need • This is unnecessarily frustrating and complex • This breaks all the time • It’s so ugly I want to vomit just so I can see something prettier • It doesn’t map to my understanding of the universe • I’m thinking about the tool, instead of my work from Scott Berkun’s article – Why software sucks 

Can you see the problem? 

This is the secret ingredient! Getting Started with DDD « Delivering software with few defects is obiously good. Still, we can reach higher for a well-designed software model that explicitly reflects the intended business objective, and our work may even reach the level of great.» Vaughn Vernon – Implementing Domain-Driven Design 

What is Domain-Driven Design? • is not a methodology • is not a framework • is not about technology • is a set of principles and practices to design high-quality software that meets core business objectives 

How to do DDD 

Model and implementation fit together The pillar 

What is a Model? • A model is an interpretation of reality that abstracts the relevant aspects to solve a problem or to meet a business goal • This part of reality represents the domain of the software • The model is distilled knowledge (we choose only what is useful) • An example? 

Ask the expert • Discussing with the domain experts can teach us a lot about the domain • Developers and domain experts work together in the same team • They need a common language to really understand and maintain the domain knowledge 

Ubiquitous language • It is a language that is used everywhere, in discussions with the domain experts, in documentation, at the coffee machines, and even in the code, but it is not a universal language • The language is taylored to the specific domain where we use it • Defining the language is an iterative process (see Crunching Knowledge) • Changing a term in the common language is a change on the model and so a refactoring of the code (i.e. renaming classes or methods) 

For many of us this is a green toad, isn’t it? or For a biologist this is an exemplar of Pseudepidalea viridis but What is this? 

For many of us this is a green toad, isn’t it? or For a biologist this is an exemplar of Pseudepidalea viridis but In the fairy tale of your 5 years old daughter probably this is the Prince! What is this? 

Modeling the Domain • A good approach could be to create an object model with the object-oriented paradigm and the SOLID principles in mind • We could use these tactical patterns 

Model-Driven Design « A design in which some subset of software elements corresponds closely to elements of a model. Also, a process of codeveloping a model and an implementation that stay aligned with each other. » Model Design Paradigm Eric Evans - Domain-Driven Design (Glossary) 

Isolating the Domain Another pillar 

How to isolate the Domain? • In a layered architecture the domain model lives in the domain layer • Keep the separation through interfaces and the dependency injection 

Entities • They model a specific concept of the domain • They are composed by attributes, associations and what is more important, the behavior • They have a lifecycle that can change their form and content, while a thread of continuity must be maintained • We must assign them an identity so they can be tracked 

Value Objects • They describe some characteristics of a thing • The identity is made of all their attributes • They are immutable • We care only about what they are, not who they are • Some examples: color, money, address (maybe, not always), … 

Services • They express an operation in the model that doesn’t fit well with an entity or a value object • Their names and usage should be part of the ubiquitous language • They are first-class citizens of the domain model • They are always exposed as an interface • Are stateless, in fact they are often implemented with a singleton • They belong to the domain layer • Sometimes, they act as coordinators « Sometimes, it just isn’t a thing. » 

The Lifecycle of a Domain Object • Every object has a lifecycle • Some spend all their lives in memory, from the constructor to the garbage collection • Other objects have longer lives and need to be persisted to maintain their integrity 

Aggregates • The domain model is composed of clusters of associated objects, called aggregates, that are a unit for the purpose of data changes • Each aggregate has a root and a boundary • The boundary defines what is inside the aggregate • The aggregate root is a single specific entity that maintains data consistency on each transaction 

Factories • When the creation of an object becomes complicated or it reveals too much of the internal structure, we should delegate that responsability to another object (or function) • We can choose from the Creational Patterns: • Abstract Factory • Factory Method • Builder 

Repository • It isolates the domain from the responsability of persisting the changes of the object model • It decouples the client from the storage technology • It provides testability using collections in memory « Mediates between the domain and data mapping layers using a collection-like interface for accessing domain objects. » Martin Fowler – PoEAA 

Domain Events • They register what happens in the domain • Other systems can listen to them and react • They can represent the state (and the history) of an entity 

Maintaining Model Integrity Last but not least 

Bounded Context • In a large project there are many models • Every model applies in a different context • Define the bounded context in which a model applies • Keep the model pure • Integration across the boundaries will involve some translation, which you can analyze explicitly 

Create a context map to know your boundaries and prevent invasions 

AntiCorruption Layer (ACL) • Layer built to integrate the bounded context with an existing system where we don’t have control (i.e. legacy or external systems) • Translate conceptual objects or actions from one model to another • It can be developed as a façade or an adapter Legacy Application «My new DDD Application» 

So, finally… 

How to develop well-designed software • Developers and domain experts have to work together • They share a common language from discussions to the code • Define a model that is strictly bound to the implementation • Isolate the domain from responsability like storage and UI • Define a context map to maintain the model integrity • Use an iteration process to fit well with knowledge crunching • Stay focused! A quick recap 

What kind of applications is DDD suitable for? 

Resources Domain-Driven Design Tacklin Complexity in the Heart of Software Implementing Domain-Driven Design Domain-Driven Design Quickly Refactoring Improving the Design of Existing Code • DDD Community (http://domaindrivendesign.org/) • Domain-Driven Design Yahoo Group (https://groups.yahoo.com/neo/groups/domaindrivendesign/info) Freely available on InfoQ website (previous registration) Eric Evans Vaughn Vernon Martin Fowler by Abel Avram & Floyd Marinescu 

Credits Le immagini contenute in questa presentazione delle quali non è stata esplicitata la provenienza hanno licenza Creative Commons Slide 2 – Somicro iconset by Veodesign (http://www.veodesign.com) Slide 4 – https://www.flickr.com/photos/dchertousov/2482084737/ Slide 12 – https://www.flickr.com/photos/davidhc/393176597/ Slide 13 – https://www.flickr.com/photos/guybrariang/7074285227/ Slide 15 – https://www.flickr.com/photos/furryscalyman/3633927491/ Slide 19 – https://www.flickr.com/photos/diversey/2498847226/ Slide 28 – https://www.flickr.com/photos/giesenbauer/5218698802/ Slide 29 – https://www.flickr.com/photos/euthman/6032536156/ Slide 31 – https://www.flickr.com/photos/angrodz/5404250882/ 

Thank you!