Table of Contents |
---|
Agenda
Done | Est time | Purpose | Action | Note taker |
5mns | Effectiveness & efficiency | Review this proposed agenda. | Nimisha | |
25mns | Context-switch into DDD mindset. | We will read and discuss the following pages from DDD Reference:
| Robert | |
10mns | Review Domain Vision Statement | edX DDD Domain Vision Statement | Dave | |
25mns | Identify Domain Use Cases |
| ||
5mn | Break | |||
20mns | Comparison of models | Compare identified "use cases" with our previously identified "jobs" | Shelby | |
(in progress) | 40mns | Core Domains Diagram |
| George |
5mn | Break | |||
(next time) | 30mns | Context Map? |
| |
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.
- What is a course? What is a course run?
- Large codebase, multiple models is inevitable.
- 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.
- 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.
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
- Support Educators
- 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
- Actionable Data and Feedback
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
User Type | Motivation | Jobs | Use Cases | Core/Supporting/Generic |
---|---|---|---|---|
Educators |
| Content Authoring |
| Core
|
Course Management |
| Core
| ||
Research to Improve Learning |
| Supporting | ||
| Supporting or Generic? | |||
| Supporting or Generic? | |||
Learners |
| Course Discovery |
| Supporting or Generic? |
Learning |
| Core
| ||
Assessment; Learning from Others |
| Supporting or Generic? | ||
Accreditation |
| Supporting or Generic? | ||
Admins |
|
| Supporting | |
Learner Acquisition |
| Supporting |
...
- 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)