Agenda

Est time	Purpose	Action	Note taker
3mns	Effectiveness & efficiency	Review 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
20mns	Identify Core Domains	Complete last column of Modeling Session, 2018-03-08#IdentifyCoreDomains	Robert
20mns	Identify Segregated Core	Given the Core from previous step, identify the Core of the Core
5mn	Break
40mns	Identify 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
20mns	Context Map	Identify relationships between the bounded contexts from previous step e.g., "Bounded Context Map" in Domain-driven Architecture Diagrams Draw relationships between the bounded contexts
5mn	Break
30mns	Components 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
20mns	Assess Model	Examine model based on recent volatility Does Single Responsibility principle hold?

Bounded Context 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

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

Core Domains:

Supporting Domains