Agenda

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

Take a stab at identifying the core/supporting/generic

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