Agenda

Notes:

•  DDD Reference Notes:
  • Bounded Context discussion (p2):
    • Large codebase, multiple models is inevitable.
      • Nimisha Asthagiri (Deactivated): Embrace this, but get clear on bounded contexts.
    • Organization and Architecture reflect each other.
    • Illustration:
      • What is a course?  What is a course run?
        • LMS: XBlock content.  Not strong association between runs.
        • ECom/Discovery: What it calls a course and what it knows about a course is different.
  • Ubiquitous Language (p3?)
    • Important that all stakeholders are involved.
    • Language must be consistent within a bounded context.
    • Hopefully, the same language will be used across contexts when and where a concept applies.
    • Document this and help with onboarding: how and where is this captured?
    • Someday get clear on how much we are willing to update code to match changes in Ubiquitous Language.
    • Do not allow the same word to mean two different things in the same in the context.
  • Core Domain (p40):
    • We define Core as Core for today, and not necessarily the future.  Could evolve as the company pivots.  Might help us make faster progress on deciding.
    • Questions about whether core could change?  Or maybe the pure core would never change?
    • Assign best developers here.
  • Generic Subdomains (p41)
    • Discern your core.  Dusting off what you first think is core might end up being a generic subdomain, in which case you might choose something off-the-shelf.
    • Notifications is an example.  Payments is an example.
    • Don't assign best developers here.  They won't pick up core domain knowledge.
  • Supporting
    • Supports core but not generic.
  • Example:
    • Game Engines might be generic and you might be required to do your own specific game engine if your use cases are more specific and required.
• Domain Vision Statement