Domain Driven Design Day 2

1
Domain Driven DesignDay 2
2
DDD Supple DesignInviting to changeReveals a
deep modelBut has no formula

• when complexity is holding back progress,
  honing the most crucial, intricate parts to a
  supple design makes the difference between
  getting sucked down into legacy maintenance and
  punching through the complexity ceiling (Evans)

3
Supple Design Overview
Side-Effect-FreeFunctions
make composition safe
UbiquitousLanguage
make safe and simple
Assertions
draw from
Intention-RevealingInterfaces
make side effects explicit
Model-DrivenDesign
simplify interpretation
express model through
Closure of Operations
StandaloneClasses
simplify interpretation
may use
reduce cost of change
ConceptualContours
4
SD Intention-Revealing InterfacesSeparation of
Interfaceand ImplementationSense of effect,
purpose
UbiquitousLanguage
draw from
Intention-RevealingInterfaces
Model-DrivenDesign
express model through

• Name classes and operations to describe their
  effect and purpose, without reference to the
  means by which they do what they promise. ()
  These names should conform to the Ubiquitous
  Language so that team members can quickly infer
  their meaning. (Evans)

5
SD Side-Effect-Free FunctionsCommands
queriesState Change ? Future OperationsAnticipa
tion
Side-Effect-FreeFunctions
make safe and simple
Intention-RevealingInterfaces

• Strictly segregate commands () into very
  simple operations that do not return domain
  information. Further control side effects by
  moving complex logic into VALUE OBJECTS when a
  concept fitting the responsibility presents
  itself. (Evans)

6
SD AssertionsEntities system
statePre-/post-conditionsSpecification Unit
testing
Side-Effect-FreeFunctions
make composition safe
make safe and simple
Assertions
Intention-RevealingInterfaces
make side effects explicit

• State post-conditions of operations and
  invariants of classes and aggregates. () Seek
  models with coherent sets of concepts, which lead
  () to infer the intended assertions,
  accelerating the learning curve and reducing the
  risk of contradictory code. (Evans)

7
SD Conceptual ContoursMonolithic
constructsDifferent conceptsmixed
togetherCohesive Units
Model-DrivenDesign
ConceptualContours
reduce cost of change

• Decompose design elements () into cohesive
  units (). Align the model with the consistent
  aspects of the domain that make it a viable area
  of knowledge in the first place. (Evans)

8
SD Standalone ClassesInterdependenciesMental
overload Modules, aggregatesEven more low
coupling
Model-DrivenDesign
StandaloneClasses
simplify interpretation

• Eliminate all other concepts from the picture.
  Then the class will be completely self-contained
  and can be studied and understood alone. Every
  such self-contained class significantly eases the
  burden of understanding a module. (Evans)

9
SD Closure of OperationsHigh-level
interfacewithout dependencyImplementer
-Argument -Return Value
Intention-RevealingInterfaces
simplify interpretation
Closure of Operations
StandaloneClasses
may use

• define an operation whose return type is the
  same as the type of its argument(s). () Such an
  operation is closed under the set of instances of
  that type. (Evans)

10
SD Declarative DesignExecutable
SpecificationRule-based ProgrammingSpecialized
FrameworksDomain-specific LanguagesDeclarative
Style of Design
11
SD Declarative Style of DesignBusiness
RulesSpecification(validation-selection-creation
)Kind of predicate(can be combined using
logical operations closed under predicates)
Specification
Object
satisfied by
12
SD Declarative Style of Designpublic
interface Specification boolean isSatisfiedBy(
Object candidate ) Specification and (
Specification other ) Specification or (
Specification other ) Specification not()
13
SD ProcedureEncapsulate complex logic in
specialized VALUE OBJECTS with SIDE-EFFECT FREE
FUNCTIONS.Write simple state-modifying
operations, characterized with
ASSERTIONS.Decouple model concepts (using a
minimum of other types).Use a familiar
formalism to make the protocol easy to grasp.