Ronald Brachetti

@rbra_

#Domain Driven Design

Image CC-BY Erik Drost (Flickr)

# topics

• me
• motivation
• ddd
• ubiquitous language
• bounded contexts
• aggregrates & value objects
• events
• discussion

# Motivations

• different teams / same codebase / same database
  • fractured code
  • fractured meaning / domain knowledge (define Trade Item)
  • code quality problems arise
  • merge conflicts → less refactoring → un-clean code
• risks of diversifying technology stack
   
• separation of concerns
• DRY (behavior)
• "Tackling complexity in the heart of software"

technical aspects

# Motivations

• Conway's Law [Conway68]
  Organizations which design systems […] are constrained to produce designs which are copies of the communication structures of these organizations.
   
• requirements evolve within certain context
• it is contexts that interact, not technical systems
• inconsistent/incongruent language
  • Trade Item in context of trade or supply may not mean the same. Think about the business rules.

social aspects

# Motivations

what actually happens

# DDD

books

Eric Evans, 2004

Vaughn Vernon, 2013

# Technical patterns

# Strategic Patterns

# why is that so powerful?

• Unambigous terms within domain
  • less friction, technical and social
• Clear paths / language between domains
  • again: less friction, technical and social
• reduced complexity reduces other issues
  • e.g. on-boarding, documentation, BDD

# ubiqitous language

"At first, the expert had to explain elementary X issues to me, and I had to explain what a class diagram/gherkin specification meant. But as the project proceeded, any of us could take terms straight out of the model, organise them into sentences consistent with the structure of the model, and be unambigously understood without translation."

Eric Evans, DDD 2004

hard, so WHY the effort

# Knowledge crunching

• Iteratively explored, knowledge-rich model
• team of knowledge experts and engineers (and designer)
• abstractions are helpful -still a model!-, but without feedback and collaboration models will turn out to be naive and lack a deep connection to the domain expert's way of thinking
• domain expert knowledge is also fractured and seldom consistent!

Knowledge crunching is an exploration,
and you can't know where you end up.

hard, so WHY the effort

# Communication

• Model needs to pervade every medium of communication (gherkin, tests, stories, documentation, slack, code!)
• Translation muddles model concept in every direction
• The vocabulary of that UBIQUITOUS LANGUAGE includes class names and prominent operations (e.g. CQRS, Events, Aggregrates)
• Committed to using the language [..] developers point out imprecision or contradiction

→ Use the model as backbone of a language

→Commit to using that language in all contexts and comms

And the use of language

# Bounded contexts

• Every model only makes perfect sense in the right context
• Every one of our products will probably end up with several bounded contexts
• Separate based on organisation, usage within application, physical manifestations, communication, etc.
• bounded contexts are bound to product domains, are bound to squads
• great fit with microservices

→One team, one language

→Design for Conway upfront

and the boundaries of a model

# context Maps

• A CONTEXT MAP is in the overlap between project management and software design
• separate and integrate, maintaining integrity of meaning
• both teams integrating should own the CONTEXT MAP and the interface
• great fit with EVENTs and EVENT STREAMING

contexts need to talk as well

# entities

• An ENTITY has an Identity, which is unique within BOUNDED CONTEXT
• Name is part of the UBIQUITOUS LANGUAGE
• Knows and can check its own validity

model aspects with a mission

# value objects

• VALUE OBJECTS have no Identity,
• Immutable
• Name is part of the UBIQUITOUS LANGUAGE

for data

# aggregates

• AGGREGATES are a tree of ENTITES and/or VALUE OBJECTS with one ENTITY at the root
• Interact with AGGREGATE only through the root
• Builds up and validates internal state

→ This is where the model really lives

Where the model comes to party

# glossary

• aggregate a cluster of associated objects that are treated as a unit for the purpose of data changes. External references are restricted to one member of the aggregate, designated as the root. [..]
• bounded context The delimited applicability of a particular model. [It] gives team members a clear and shared understanding of what has to be consistent and what can develop independently.
• context the setting in which a word or statement appears that determines its meaning
• context map A representation of the bounded contexts involved in a project and the actual relationships between them and their models
• domain a sphere of knowledge, influence or activity

• domain expert A member of the software project whose field is the domain of the application, rather than software development. Not just any user of the software, the domain expert has deep knowledge of the subject
• entity An object fundamentally defined not by its attributes, but by a thread of continuity and identity.
• model A system of abstractions that describes selected aspects of a domain and can be used to solve problems related to that domain.
• model-driven design A design in which some subset of software elements corresponds closely to elements of a model.
  Also, a process codeveloping a model and an implementation that stay aligned with each other

# glossary

• repository A mechanism for encapsulating storage, retrieval, and search behavior which emulates a collection of objects.
• service An operation offered as an interface that stands alone in the model, with no encapsulated state.
• ubiquitous language A language structured around the domain model and used by all team members to connect all the activities of the team with the software.
• value object An object that describes some characteristics or attribute but carries no concept of identity.

# glossary