Agenda

Done	Est time	Purpose	Action	Note taker
	5mns	Effectiveness & efficiency	Review this proposed agenda.	Nimisha
	25mns	Context-switch into DDD mindset. (review for some, new for some) Remember and align on terms.	We will read and discuss the following pages from DDD Reference: p 2 Bounded Context p 29 Context Map pp 39-46 Section V	Robert
	10mns	Review Domain Vision Statement	edX DDD Domain Vision Statement	Dave
	25mns	Identify Domain Use Cases	See "Business Use Case Diagrams" in Domain-driven Architecture Diagrams See p28 of http://www.ntcoding.co.uk/workshops/strategic-ddd-practices Possibly use Trello for this
	5mn	Break
	20mns	Comparison of models	Compare identified "use cases" with our previously identified "jobs"	Shelby
(in progress)	40mns	Core Domains Diagram	See p32 (Core Domains Diagram) of Strategic DDD Practice Read DDD: Strategic Design: Core, Supporting, and Generic Subdomains Possibly in 2 smaller groups Take a stab at identifying the core/supporting/generic Use Google diagrams for this	George
	5mn	Break
(next time)	30mns	Context Map?	Identify high-level bounded contexts and their relationships e.g., "Bounded Context Map" in Domain-driven Architecture Diagrams
	15mns	Identify Next Steps

Notes

DDD Reference

• 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.
    • It doesn't make sense for a small company to make their own generic game engine. Can't compete on breadth of features.
    • It may make sense for them to do something very specialized to their game.

Review Domain Vision Statement

• Was made by Engineers
• Takes strong stances on revenue, open source (last two paragraphs)
• Reads as high level business strategy, not clear how it relates to arch in core
  • According to DDD, this is appropriate, and there's another doc that goes with this to bridge the two.
• Trickiness of defining Core is understanding the business strategy better.
  • What's the timeline of "Vision Statement"?
  • Expectation that the Core will evolve over time.
  • Do we focus on only what we're doing now instead? Example of revenue.
    • There's still some core of edX that won't radically change regardless.
    • The elevator pitch for edX doesn't need monetization details.
    • Is Open Source core in that sense?

Identify Domain Use Cases

• User types:
  • Learners
  • Educators
  • Admins (wants reports on their students)
  • Researchers
• Educators (what they need, from Shelby's presentation) + Researchers
  • Support Educators
    • Easy Authoring and Administration of Courses
    • Communities of Practice
    • Actionable Data and Feedback (Insights + Data package)
  • Teaching at Scale
    • Course Design
    • Educational Blocks (Teaching and Assessment)
    • Supporting Learners (Community and Mentorship)
  • Experimentation
• Learners
  • Discovery: Find the right course/program to help them achieve their goals
  • Achieve Learning Outcomes
    • Rigor/quality of instruction
  • Support through their learning pathway – progress, messaging, social
  • Proof of Learning, credentials/certifications
• Admins
  • Actionable Data and Feedback
    • What are my students doing 
    • Am I getting my money's worth
  • Setting up edX for their org
    • Curation
    • Integration

Comparison of Models (Use cases versus Jobs)

• Enterprise seems like there's more we could include in our Use Cases. Motivations: upskilling employees, employee retention.
• Should we include motivations for each customer group?
• From the edx perspective, we have to distribute and host content. As a customer, I just need to be able to access content.

Brainstorm of customer motivations

• Educators:
  • I want to teach millions of learners around the world, and know my time is a good investment. 
  • I want to improve as an educator.
  • I want to elevate my brand and attract millions and millions.
  • I want to connect with and learn from a community of educators.
  • I want to make money.
  • I want to do academic research and publish some papers. 
  • I want to effectively, and easily do my job (course build, course run, learner management, data review).
• Learners:
  • I want to learn, so that I can improve my life (career change, improve my job, raise, change roles, fulfill educational requirements).
  • I am a lifelong learner.
  • I want to connect with others in similar fields of interest.
• Enterprise Admins:
  • I want to effectively, and easily do my job (course curation, employee management, data review).
  • I want to know my time and my employee's time is a good investment.
  • I want to upskill my employees.
  • I want to validate completion of internal requirements (legal / business policies).
  • I want to retain my employees (a benefit).
  • I want to create a pathway for my employees.

Identify Core Domains

...

• What is core - supporting technology for courseware (xblocks) versus the blocks themselves
• What is the goal of identifying core?
  • As engineers: One thing we need to make sure we do right
  • Tackling monolith: Core to designate what to decouple from monolith - focused effort - 80% of time
  • For management: Identify pontential disconnect between eng/prod and leadership - do we agree on core
    • Resourcing
    • Management needs to support the focus on core

Next Steps

• Finish Core column on table - timeboxed effort
• Bounded Contexts - Core may influence this (are there multiple bounded contexts in play)