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