Domain Driven Design Day 2 DDD Supple Design

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

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

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

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

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

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

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

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) Specification {satisfied by} Object Kind of predicate (can be combined using logical operations; closed under predicates)

SD | Declarative Style of Design public interface Specification { boolean is. Satisfied. By( 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.