Page Comparison

...

•  DDD Reference Notes:
  • 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:
  • 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.

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
  • Dave: One thing we need to make sure we do right
  • Resourcing
  • Management needs to support the focus on core
  • Core to designate what to decouple from monolith - focused effort - 80% of time
  • Identify pontential disconnect between eng/prod and leadership - do we agree on core

Next Steps:

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