beEer soFware more easily by focusing on the domain instead of the technology A so>ware is good if its capacity to process problem related to the domain is good – When the domain is complex the so>ware is a lot more difficult to build and maintain. DDD brings solu+ons to manage the domain and so>ware complexity.
by the so>ware which helps solving problem related to the domain – Examples : front-‐office finance, tax, e-‐commerce, accoun+ng, so>ware (IDE, Modeler) , electronics, etc. The domain represents a sphere of knowledge
driven by Models located in par+cular Contexts. Models are explorated in a crea+ve collabora+on of domain and so>ware prac++oners. • An Ubiquitous Language is used to communicate between the technical and the business side Building blocks • En+ty • Value Object • Service • Aggregate • Repository • Factory • Domain Event • Layered Architecture Design principles • For design suppleness : Supple design • To preserve the model’s integrity, manage the design effort and the priority : Strategic design
literal way to represent the domain model in terms of so>ware – The model should balance these 2 requirements: form the ubiquitous language of the development team and be representable in code Tightly rela3ng the code to an underlying model gives the code meaning and makes the model relevant Changing the code means changing the model Refining the model requires a change to the code
Design ac3vity is made of every decision made during the project Business analyst are designers Developers are designers, at a very fine grained detail level Design documenta3on is all about « Why ? » and the answers leads to the goals and constraints stated at project incep+on Design ac3vity goals is to deliver the best solu3on to the users given the project constraints : scope, resources, +me and the most important one, quality. « by « design » we mean a way of organizing the domain concepts, which in turn leads to the way in which we organize their representa+on in code » Eric Evans (noun) a specifica+on of an object, manifested by an agent, intended to accomplish goals, in a par+cular environment, using a set of primi+ve components, sa+sfying a set of requirements, subject to constraints (verb, transi5ve) to create a design, in an environment (where the designer operates
» G. Box, sta5s5cian A system of abstrac3ons that describes selected aspects of a domain A model describes a material or immaterial reality with a par3cular filter by using some concepts that allows classifying the observed reality : these filtering concepts goes into a paradigm and are formalized through a metamodel A model is a limited and oriented descrip+on of reality A model forms the basis of a language
the non significant details and focus on the essen3als Abstrac3on is the act of isola3ng some objects shared characteris3cs In IT, it’s also the act of hiding a component implementa3ons details (object, system) that also leads to the encapsula+on and interface concept. Why abstrac+on ? because a human brain can only manage at most 5 elements at a 3me (3 actually according to some psychological studies...) It’s the modeler’s fundamental intellectual tool It separates the responsability on a ver3cal axis
isolate domain with encapsulate with ENTITIES VALUE OBJECTS LAYERED ARCHITECTURE AGGREGATES REPOSITORIES act as root of SMART UI X FACTORIES encapsulate with express model with encapsulate with mutually exclusive choices access with maintain integrity with access with SERVICES express model with
Applica3on Services User Interfaces Tests Infrastructure WS and Messaging Databases Programma3c Interfaces • An independent object model serves as the founda+on of the applica+on. • Interfaces are defined by inner layers, and implemented by outer layers. • All couplings are directed towards the center of the “onion” • It is possible to compile and run the core code of an applica3on separately from the infrastructure. • It uses the Dependency Inversion Principle So>ware Architecture – from Layers to « Onion »
Name classes and opera+ons to describe their effect and purpose, without reference to the means by which they do what they promise Side-‐Effect-‐Free func3ons opera+ons that return results with no observable side effects Asser3ons State post-‐condi+ons of opera+ons and invariants of classes and aggregates Standalone classes Self-‐contained class with no external dependencies Closure of opera3ons An opera+on whose return type is the same as the type of its arguments in order to keep away dependencies against another types
a par+cular so>ware, a company’s department, etc. Context integra3on Use the Upstream/Downstream metaphor. Different « levels » : An+corrup+on layer, conformist, shared kernel, Customer/Supplier rela+onship, separate ways, open host Design effort prioriza3on Dis+lla+ons : core, support and generic domains Large scale structure Evolving Order, System Metaphor, Responsibility Layers, Knowledge Level, Pluggable Component Framework Core idea : each model and its concepts are located in a par3cular context
Conformist Customer/Supplier teams OpenHost service Shared Kernel Single Bounded Context Control of all associated systems Communica+ons commitment/capability of teams
• Deals with Core Domain ? • Or has intricacy in the domain/ problem area you are trying to address ? • Or needs to bring clarity ? • Or has business exploring ? not so>ware exploring. If they know what their goal is, but they don't know quite how to accomplish it. Need so>ware development that can explore with them Do you have what it takes to make it work? Can you make it work? • Clean bounded context • Access to domain experts. You must obtain access to domain experts, and then establish a real rela+onship, a crea+ve collabora+on • Skilled team • You want your internal team focused on the Core Domain because that is where the most valuable, specialized knowledge is. You want that core team accumula+ng knowledge and skills in the core domain. If you outsource, you may get a good piece of so>ware but not that accumulated knowledge
with isolate domain with encapsulate with ENTITIES VALUE OBJECTS LAYERED ARCHITECTURE AGGREGATES REPOSITORIES act as root of SMART UI X FACTORIES encapsulate with express model with encapsulate with mutually exclusive choices access with maintain integrity with access with SERVICES express model with
with isolate domain with encapsulate with ENTITIES VALUE OBJECTS LAYERED ARCHITECTURE AGGREGATES REPOSITORIES act as root of SMART UI X FACTORIES encapsulate with express model with encapsulate with mutually exclusive choices access with maintain integrity with access with SERVICES express model with
– A color (Yellow) : determined by the propor+on of Red (0), Green (255) and Blue (255) – A bank note of 10 €. I can exchange my 10 € bank note with yours, it doesn’t make a difference to us about its usage. A value is something intangible and immutable Intangible = that exists outside +me and space Immutable = that doesn't change
focus of their domain – Some are mathema+cal: Integers, Double – Some are programma+c: strings (but with no seman+cs at all...) – Some are real world: ISBNs, Money, Dura+on, Phone Number, etc. Value types reflect constraints – ISBNs have a well-‐formedness rule – Int (32 bits) is a bounded subset of integers Some value types have an intrinsic or natural ordering – Ordering may be based on magnitude, lexicographical or ordinal criteria – Be careful about imposing an ordering on unordered types. Ordering is not an essen+al feature for all value types
1 Hour or 60 seconds Instant = seconds since 1st january 1970 00:00 |Instant 2 – Instant 1 | = Dura+on Instant 1 + Dura+on = Instant 2 Interval = start instant + end instant Timezone Chronology An Instant (point in +me) is a value, as is the difference between two Instant, but Instant, Dura5on and Interval are not equivalent types. See Joda Time Library for an implementa+on. Instant 2 Instant 1 Dura+on Time
meaningful and well-‐formed object – Par+al ini+alisa+on is problema+c for objects — especially for value objects – Consider the constructor to be transac3onal: it returns a correct object or an excep+on Respect and enforce state invariant Comparison… – Equality is a fundamental concept – Total ordering may or may not apply Classifica3on and conversion… – Avoid inheritance and favor composi+on – May support conversions (Km -‐> Miles), (Hour -‐> Second) Value Object Smells : – Anemic Value Object : Lizle behaviour beyond field access – Role creep : Too much responsibility and external dependencies – Non-‐meaningful constructor – Constructor without useful enforcement or sufficient quality of failure
– purpose: data transfer – technical construct – bunch of data – not necessarily coherent – no/lizle behaviour VO – Value Object – purpose: domain representa+on – high-‐coherent data – rich on behaviour « Data Transfer Object is an oxymoron. » Dan North, Qcon London 2011 Conference
conceptual iden5ty. These objects describe some characteris5c of a thing. • Tracking the iden+ty of en++es is essen+al, but azaching iden+ty to other objects can hurt system performance, add analy+cal work, and muddle the model by making all objects look the same. • So>ware design is a constant bazle with complexity. We must make dis+nc+ons so that special handling is applied only where necessary. However, if we think of this category of object as just the absence of iden+ty, we haven’t added much to our toolbox or vocabulary. In fact, these objects have characteris+cs of their own, and their own significance to the model. These are the objects that describe things. Therefore • When you care only about the aEributes of an element of the model, classify it as a value object. • Make it express the meaning of the aEributes it conveys and give it related func3onality. • Treat the value object as immutable. • Don’t give it any iden3ty and avoid the design complexi3es necessary to maintain en33es.
Adding new terminology to language Compound value objects can swallow lots of computa3onal complexity Provides advanced language En3ty relieved of complexity Uses advanced language Improved extensibility Especially clarity, testability and concurrency issues
iden3ty whatever values their states or azributes are Iden33es are mental tools we use to superimpose con3nuity on a world which is constantly, func3onally, crea3ng new values of itself By iden+ty we mean a stable logical en+ty associated with a series of different values over +me An En5ty is an object that is not defined by its azributes but rather by a thread of con+nuity and its iden+ty
iden3ty and a state, so: What does it means to be the same thing ? How dis+nguish between two different objects ? Its naming uses a nominal group that refers to something or a role Examples : A credit card : has an iden+ty (number) and a state, that’s why there is a chip in it in Europe A person in a plane is an En5ty because a seat is associated with her. A person in a bus is a Value Object because her iden+ty doesn’t mazers (or with low-‐cost air carrier). It depends of the context…
defined by their aOributes, but rather by a thread of con5nuity and iden5ty. • Some objects are not defined primarily by their azributes. They represent a thread of iden+ty that runs through +me and o>en across dis+nct representa+ons. Some+mes such an object must be matched with another object even though azributes differ. An object must be dis+nguished from other objects even though they might have the same azributes. Mistaken iden+ty can lead to data corrup+on. Therefore • When an object is dis3nguished by its iden3ty, rather than its aEributes, make this primary to its defini3on in the model. • Keep the class defini3on simple and focused on life cycle con3nuity and iden3ty. • Define a means of dis3nguishing each object regardless of its form or history. • Be alert to requirements that call for matching objects by aEributes. • Define an opera3on that is guaranteed to produce a unique result for each object, possibly by aEaching a symbol that is guaranteed unique. This means of iden3fica3on may come from the outside, or it may be an arbitrary iden3fier created by and for the system, but it must correspond to the iden3ty dis3nc3ons in the model. • The model must define what it means to be the same thing.
way of establishing its iden+ty with another object—dis+nguishable even from another object with the same descrip+ve azributes An iden+fying azribute must be guaranteed to be unique within the system however that system is defined—even if distributed, even when objects are archived See UUID, Master Data Management Mechanisms, etc.
state of other (en3ty) objects. What is interes+ng about them is not their iden+ty but the value that they represent From a programming perspec+ve, we can model values as objects – Hence value objects and value types – Value objects have significant state but insignificant iden+ty – A value object is a kind or style of object that realises a value
En3ty Mutability Should be immutable Usually mutable Equality Compare by value, as in a.equals(b) Compare by iden+ty, as in a==b Scale Typically small in scale Of any size Serializability Should be serializable; may be parseable Need not be serializable Defaults O>en have a natural default: the number 0, or “today » No natural default Comparability O>en have a natural order: 1, 2, 3. . . Typically no natural sort order Closure (or Algebra) O>en have a closed set of opera+ons: 2 + 2 = 4 Unlikely to have any closed set of opera+ons Iden3ty May represent an iden+fier, such as an SSN Something that is iden+-‐ fied, such as a Person User Interface Have dedicated widgets: checkbox, calendar. . . Coded by hand
17, 1940) is an American computer scien+st, known for his early pioneering work on object-‐oriented programming (with Smalltalk) and windowing graphical user interface design, and for coining the phrase, "The best way to predict the future is to invent it.” "OOP to me means only messaging, local reten6on and protec6on and hiding of state-‐process, and extreme late-‐ binding of all things.” Alan Kay http://www.purl.org/stefan_ram/pub/doc_kay_oop_en
past par3ciple that have a sta3c and stable meaning (paid order, loggued user, etc.) State influences the object’s behavior State, in its defini+on, imply that between several different stable states, there are en+ty’s transforma3ons occuring during a state transi6on triggered by an event A state is associated with an iden6ty in order to track the different state transi5ons A state is a rela+on among individual en++es and values at a par+cular instant; it can change over +me
data in the Informa+on System Immutable, con+nuous Immutable, con+nuous Mutable, con+nuous Mutable, discrete Immutable, con+nuous Immutable, discrete Events that triggers state transi+on
Single Married Adult Minor Time Adult state Marital state Divorced • Business Id : 12345678 • John • Doe • 5 November 1976 in Paris • … En3ty State En5ty Object at a given moment in +me Iden3ty State
OO and FP State Iden3ty State 1 State 2 State 3 Func+on Func+on Event triggers Event triggers • value 1a • value 1b • value 1c • value 1a • value 1b • value 1c • value 2a • value 2b • value 1a • value 1b • value 1c • value 2a • value 2b • value 3a Publish Internal Event Publish Internal Event ... Time
Submized Paid Shipped pay ship Payment details from Payment Gateway received Carrier data q Customer Data q Product Lines (product + qty) q Shipping Data States submit q Customer Data q Product Lines (product + qty) q Shipping Data q Payment Data q Customer Data q Product Lines (product + qty) q Shipping Data q Payment Data q Carrier Data Front website form submized Order submized event Order paid event Order shipped event Time
behavior and an iden3ty. Encapsula3on allows to focus on the external proper3es, the object interface, while hiding internal mechanisms. Objects communicates by messages through rela3onships. Class defines objects set that share the same proper+es. Class are object factory. Generaliza3on rela+onship allows to factorize common proper+es and permits polymorphism. Object lifecycle is described by a finite state machine that react to events.
of composing func3ons with other func+ons to solve problems Immutability [and no side-‐effects but to a certain degree according to the interlocutor’s religion, Haskell or Lisp] Few Data Structures, Lot of Opera3ons Recursion Lazyness First-‐Class Func3on Immutability Recursion/Lazyness
experts : what is the value the domain expert acquired during the modeling process? it must be a crea+ve process Explora3on and experimenta3on : exploring model is really cheap (on the black board), we do not finish un+l we produce 3 bad models, if you only produce good things you are not crea+ve. We need to discuss, let's celebrate the bad ideas ! Emerging models shaping and reshaping the ubiquitous language Explicit context boundaries Focus on the core domain
Make the implicit explicit Get real and concrete usage through scenarios There is no one model to rule them all: every model is +ed to a context Not all domains are equivalent, some are more important than other : the core domain Collabora5on between domain expert and so>ware expert is the key : if you want to go fast, go alone, if you want to go far, go together...
jgrodziski
akatsuki174
kuroruri
yammerjp
yamannnu
mackey0225
akki_megane
yutaron
joergneumann
tasuku43
komtaki
paweldabrowski
panda_program
jnunemaker
paigeccino
edds
colly
maltzj
philnash
shlominoach
jcasabona
morganepeng
jonyablonski
smashingmag
bryan
