Domain-Driven Design is a set of principles and practices to design high-quality software that meets core business objectives. In this session I will show you how to apply it.
applications. Currently I’m particularly interested in agile software development, Domain-Driven Design, CQRS and NoSQL databases. Software Architect at
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/
• 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
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
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
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?
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
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)
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?
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)
• 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
• 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), …
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. »
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
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
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
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
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
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»
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
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
manuelscapolan
bkuhlmann
ikumatadokoro
josepaumard
okashoi
utgwkk
jaguar_imo
xhochy
riofujimon
onomax
kazamori
carmenintech
thekraken
tanoku
ammeep
morganepeng
nonsquared
palkan
samlambert
addyosmani
shpigford
thoeni
swwweet
