Graduate Program KB

Domain Driven Design

The Domain Model

  • Model
    • Represents some aspect of reality that is of interest
    • Simplification
    • Abstracts aspects relevant to solving the problem
    • Ignores extraneous aspects
  • Domain
    • Subject area to which the user applies the program
  • Development teams must use knowledge related to activities the software performs
    • Lots of domain knowledge, too much to deal with
    • Use a model - makes sense of information and focuses it on a problem
  • Domain model
    • Rigorously organized and selective abstraction of domain knowledge
    • Can be represented in a diagram, english, code, ...
    • Chosen for utility, not the most "realistic"
  • Choice of a model
    • Model and the heart of the design shape each other
      • Link between model and implementation makes the model relevant
      • Helps development and maintenance - code can be interpreted based on an understanding of the model
    • Model is the backbone of a language used by all team members
      • Developers can talk about the problem in this language - binding between implementation and model
      • Communicate with domain experts without translation
      • Natural linguistic abilities can be used to refine the model
    • Model is distilled knowledge
      • Team's agreed upon way of structuring domain knowledge and distinguishing elements of most interest
      • How we choose to think about the domain
  • Heart of software
    • The ability to solve domain related problems for the user
    • Focusing on precise execution of a particular specialty misses the big picture

Knowledge

  1. Binding the model and the implementation
  • Initial crude prototype to test early models
  1. Cultivating a language based on the model
  • Initially have to learn domain jargon
  • Eventually anyone can take terms straight out of the model and understand without translation
  1. Developing a knowledge-rich model
  • Objects have behaviour and enforced rules - not just data
  1. Distilling the model
  • Important concepts added to model to make more complete
  • Concepts dropped when they don't prove useful 5 Brainstorming and experimenting
  • Discussions as a laboratory of the model
  • Try experimental variations to judge
  • Domain modelling
    • Take a torrent of domain information and probe for the relevant trickle
    • Many models and tried and rejected, or transformed
    • Emerging set of abstract concepts that makes sense of all the detail
  • Continuous learning
    • Projects leak knowledge
      • People move on, knowledge gets scattered
      • Code and documents don't express in a usable form
      • Knowledge gets lost
    • Highly productive teams grow their knowledge

Language

Implementation