/
Modeling Session, 2018-03-15

Modeling Session, 2018-03-15

Mar 21, 2018

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

    • 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