Please enable JavaScript.

Coggle requires JavaScript to display documents.

domain driven design - Coggle Diagram

- - - - basic strategy in the shipping domain known to everyone
      - requirement = Allow 10% overbooking
      - important business rule hidden as a guard clause in application method :frowning_face:
      - change the design to better capture this knowledge
      - overbooking rule is a policy
        Policy is another name for the design pattern STRATEGY
      - if (!overbookingPolicy.isAllowed(cargo, voyage)) return –1;
      - overbooking as a distinct and important business rule
        not just an obscure calculation
      - Programmers can show business experts technical artifacts; should be intelligible and help close the feedback loop
- - - - provides a ubiquitous language ties domain experts technologists
      - :question: greatest value of domain model
    - - reject the phased thinking of "design, then build."
      - really powerful domain models evolve over time
      - best ideas appear after initial releases of a system
  - - - bureaucracy
      - unclear objectives
      - lack of resources
    - - :key: approach to design
      - complexity out of hand
      - no longer understand enough to change or extend
    - - failure to handle domain complexity in design
      - does not matter if infrastructural technology is well conceived
      - successful design must systematically deal with this central aspect
  - - - recognises importance of design decisions
      - strongly resists upfront design
      - puts admirable effort into communication
      - developers can use "simplest thing that works"; then refactor arriving at a design fitting customer's true needs
      - minimalism = antidote to
        
        excesses of design enthusiasts
        
        cumbersome documents providing little value
        
        "analysis paralysis"; team fearing of an imperfect design
      - works best
        
        for developers with sharp design sense
        
        developers without solid design principles will produce a code base that is hard to understand or change - the opposite of agility
        
        although fear of unanticipated requirements leads to overengineering
        
        avoiding overengineering; fear of doing any deep design thinking at all
      - attempts to increase team communication;
        but model and design choices clarify or confuse communication
- - - - model and heart of the design shape each other
        
        intimate link between model and implementation makes it relevant
        
        ensures that analysis applies to the final product, a running program
        
        also helps during maintenance and continuing development
      - model is backbone of team language
        
        developers can talk about the program in this language
        
        communicate with domain experts without translation
        
        natural linguistic abilities can be turned to refining the model
      - model is distilled knowledge
        
        team’s agreed upon way of structuring domain knowledge
        
        how team distinguishes the elements of most interest
        
        how we choose to think about domain; select terms, break down concepts, and relate them