Modeling Session, 2018-03-15

Owned by Nimisha Asthagiri (Deactivated)
Last updated: Mar 21, 2018
2 min read

Agenda

Est timePurposeActionNote taker
3mnsEffectiveness & efficiencyReview this proposed agenda.Nimisha
12mns

Context-switch into DDD mindset;
Align on approach of identifying Core

Read and discuss the following pages from DDD Reference:

  • p 44 Cohesive Mechanisms
  • p 45 Segregated Core
  • p 46 Abstract Core
Gabe
20mnsIdentify Core DomainsRobert
20mnsIdentify Segregated Core
  • Given the Core from previous step, identify the Core of the Core

5mnBreak
40mnsIdentify High-level Bounded Contexts
  • Review "Fitness Functions" below
  • Identify high-level bounded contexts
  • Write each bounded contexts on Large Post-it notes and place on white board
Dave
20mnsContext Map
  • Identify relationships between the bounded contexts from previous step
  • Draw relationships between the bounded contexts

5mnBreak
30mnsComponents in Bounded Contexts
  • Write each component from edx-platform Repository Overview on Post-it notes
  • Identify missing components from other IDAs and put them on Post-it notes
  • Place these Post-it notes within each Bounded content from previous step

20mnsAssess Model
  • Examine model based on recent volatility
    • Does Single Responsibility principle hold?

Bounded Context Fitness Functions

References: https://vimeo.com/113515335, http://verraes.net/2014/02/domain-driven-design-basics/, https://www.youtube.com/watch?v=ez9GWESKG4I

Fitness Functions

  • Technical authority for a specific business capability; with all data and business rules within the context
  • Autonomous
  • Share contracts/schema, not class or type
  • Interactions controlled by policy
  • Boundaries
    • Explicit boundaries
    • Linguistic boundaries
    • Domain expert boundaries
  • Data
    • Flow
    • Ownership
    • Uniqueness
  • May consider, but may be wrong
    • Existing business process steps
    • Existing organizational boundaries

Non-Fitness Functions

  • If only functionality - then just a function
  • If only data - then just an entity or database

Notes

Identifying the Core

  • Refactoring to segregate the core feels very risky
    • Probably a lot of additional cost, without a clear cost savings
    • Isn't that true for the whole thing?
    • Hard to see and feel the value immediately
    • Hard to see the value until you have 100% identified the core
  • Abstract core
    • Didn't remember this part from the book, but like this
    • Having a clear set of base classes means we don't have to move the core classes
    • Domain model != data model
    • Can a single bounded context have both core and not core in it?
      • We don't think so...
      • There are certain generic implementation details that can be abstracted away from callers
        • In that case you have supporting things that are not "core"
  • Are data frames and matrices in our bounded context?
  • Can we think of a concrete example?
    • Course discovery is a domain
    • Search is a bounded context
    • What about the ORM for elastic search?
      • No - we wouldn't even talk about this
  • They seem to indicate that whole domains are either core, supporting or generic

Bounded Contexts

Core Domains:

  • Authoring learning component
  • Launch Course Run
  • Rich ecosystem of learning components
  • Revenue sharing
  • Learner consume content to achieve learning outcomes
  • Determining learning pathway

Supporting Domains

  • Course Administration