Domain Driven Design Day 2

DDD | Supple Design Inviting to change Reveals a deep model But … 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)

Supple Design | Overview Ubiquitous Language Model-Driven Design Intention- Revealing Interfaces Side-Effect-Free Functions Assertions Closure of Operations Standalone Classes Conceptual Contours make composition safe make side effects explicit simplify interpretation may use simplify interpretation reduce cost of change express model through draw from make safe and simple

SD | Intention-Revealing Interfaces Separation of Interface and Implementation Sense of effect, purpose “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) Ubiquitous Language Model-Driven Design Intention- Revealing Interfaces express model through draw from

SD | Side-Effect-Free Functions Commands & queries State Change  Future Operations Anticipation “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) Intention- Revealing Interfaces Side-Effect-Free Functions make safe and simple

SD | Assertions Entities: system state Pre-/post-conditions Specification Unit testing “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) Intention- Revealing Interfaces Side-Effect-Free Functions Assertions make composition safe make side effects explicit make safe and simple

SD | Conceptual Contours Monolithic constructs Different concepts mixed together Cohesive Units “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) Model-Driven Design Conceptual Contours reduce cost of change

SD | Standalone Classes Interdependencies Mental overload Modules, aggregates Even more low coupling “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) Model-Driven Design Standalone Classes simplify interpretation

SD | Closure of Operations High-level interface without dependency Implementer - Argument - Return Value “… 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) Intention- Revealing Interfaces Closure of Operations Standalone Classes simplify interpretation may use

SD | Declarative Design Executable Specification Rule-based Programming Specialized Frameworks Domain-specific Languages Declarative Style of Design

SD | Declarative Style of Design Business Rules Specification (validation-selection-creation) Kind of predicate (can be combined using logical operations; closed under predicates) SpecificationObject {satisfied by}

SD | Declarative Style of Design public interface Specification { boolean isSatisfiedBy( Object candidate ); Specification and ( Specification other ); Specification or ( Specification other ); Specification not(); }

SD | “Procedure” Encapsulate 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.