Domain Driven Design - KeynesYouDigIt/Knowledge GitHub Wiki

via Software-Development#high-level-methodologies

Domain-driven design (DDD) is a software design approach focusing on modelling software to match a domain according to input from that domain's experts.

((This seems to have A LOT to do with natural language theory, context, meaning, etc... make some links to econ/philosophy if related.))

Domain-driven design is predicated on the following goals:

  • placing the project's primary focus on the core domain and domain logic;
  • basing complex designs on a model of the domain;
  • initiating a creative collaboration between technical and domain experts to iteratively refine a conceptual model that addresses particular domain problems.

when NOT to use DDD

  • if the Domain is not that complicated (even if the software is, eg twitter).

DDD - what it is/ how to implement it

https://www.youtube.com/watch?v=pMuiVlnGqjk Eric Evans ("father" of dd?)

  • We need to start using the same language that is in our software to talk about our software.

  • Work with a domain expert and build a model

    • in software, domain:model - map:projection. By accepting a certain projection, we accept distortions that allow us to understand the domain.
    • The distortions we accept should maximize the accuracy of how our problem is represented.
      • ie, the mercator projection is good for getting between major cities. It's bad for comparing overall land size when the land is not on the same latitude.
      • what IS interesting (related to the problem we set out to solve)? what is NOT interesting?
      • The more "accurate" (detailed) your model, the harder it is to use quickly (think about memory, both brain and computer!)

  • DO NOT latch on to initial models you make with your domain expert! "test drive" them by talking through the model slowly, THEN proposing an alternate model and talking through it.

    • Constantly observe drift in language as you start to talk more about the software. For example "the cargo is loaded onto a transport at the start of a leg and unloaded at the end" becomes "a cargo's itinerary is a series of legs"
    • Developing "ubiqoutous language" PER a bounded context (NOT like, the whole company).
    • the point is to find bad ideas. if you dont find bad ideas, how do you know what good ideas are?
    • short, multiple sessions, with little to no documentation

Even on so called "greenfield" projects, from the start we will have to work with the [related] existing software. I don't like to ignore that constraint

-- EE

Bounded Contexts

https://www.youtube.com/watch?v=am-HXycfalo

  • A Bounded Context is the context related to a particular problem.
  • Good software using DDD reflects the BCs they serve (schemas, services, etc)
  • All stakeholders agree on vocabulary (to the extent possible), Devs agree on technical patterns
  • Reality often crashes the party and blurs lines, which can lead to a "3 legged race" problem (2+ teams working on a shared system with poor coordination)
  • Allow your boundaries to be real pieces of software, big (lots of work/code) if they have to be! protect borders