1 / 13

Domain Driven Design Day 2

Domain Driven Design Day 2. DDD | Supple Design Inviting to change Reveals a deep model But … has no formula.

karlp
Download Presentation

Domain Driven Design Day 2

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 simplify interpretation Model-DrivenDesign express model through Closure of Operations simplify interpretation StandaloneClasses 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 OperationsAnticipation 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 simplify interpretation StandaloneClasses • “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 | “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.

More Related