Objective
We meet every 3 weeks (off-weeks of Python Study Group and Frontend Study Group) to collectively learn about edX architecture principles and how to put them into practice in our daily engineering.
Why?
Each of us is an architect of every line of code we write, every module and abstraction we build, and every system component and service that we design. This study group allows us to learn from our past mistakes, learn from practices emerging from industry-wide experiences, and collectively align and develop our own architectural principles to follow at edX. Anticipated outcomes of edX intentional architecture include (1) sustainably accelerated development (2) improved developer engagement and (3) a more robust teaching and learning (Open) edX platform.
What?
We will begin by collectively writing and understanding more deeply the architectural principles proposed in Architecture Manifesto (WIP) (and maybe Architecture Principles (WIP)).
Schedule
Date | Topic | Presenter | Links | |
|---|---|---|---|---|
| Data Redundancy beats Coupling across Distributed Services | |||
| Extensions beat Core Modifications | |||
| Extensions beat Core Modifications, extended | In this Arch Study Group, we will build upon what we learned in the last study group. So if you could not make the last one on SOLID and Extensions, please catch up via the speaker notes in the following slides prior to attending this session: SOLID Design Principles, edX’s Path to Extensions | ||
| DDD Bounded Contexts beats Shared Business Logic | Cale will lead us through exercises and principles related to where/how to draw boundaries, using techniques and concepts from Domain-driven Design. We will discuss and apply our learnings to the edX system. | ||
| Boundaries: Cohesion, Coupling, Microservices, and Domain-Driven Design | Join me today as we study the time-old question of boundaries and modularity (cohesion & coupling). We will see how this relates to micro-services (should this be a new service or not?) This is a baseline discussion for "Why Domain-driven Design". | ||
| Bounded Autonomy beats Coordination: Reversibility & Uncertainty of Decisions | In this workshop, we will explore the 1st item in the Manifesto: Autonomy beats Coordination. We will crowd-source ideas on the reversibility of technical decisions at edX. If time permits, we will also do an exercise to calibrate ourselves on our ability to quantify the certainty of our decisions. | ||
| Thoughtworks Tech Radar Review | This week, we'll break out into groups and review items from the latest ThoughtWorks Tech Radar. | ||
| How XBlocks work in edx-platform | Come join us as Nathan Sprenkle presents what he's learned from his experiences working with the Open-Response-Assessment (ORA) XBlock He'll be answering the question, "when I visit a course on edX, what happens to get interactive course content rendered to the page?" Along the way, we'll go on an archeological adventure through edx-platform and the XBlock runtime to understand the roles they play and examine some of the clever tricks going on to assemble the different pieces. | ||
| Yoking UX & Tech: The value of customer-centricity | Stacey Messier (Deactivated) Gabe Mulley (Deactivated) Nimisha Asthagiri (Deactivated) | Stacey, edX’s Head of UX will lead a workshop (with assists from Gabe and Nim), on embedding UX into technical design and engineering. Do you know the difference between Customer Insights and Customer Centricity? Would you like hands-on experience with applying UX insights into your technical design? Is there a value in doing so? Don’t take our word for it. Come and experience it! | |
| Moving & Building Boxes of Domains and Bounded Contexts Theme Strategies -> Conway -> Arch Boundaries -> Ownership | Let's plan to rebuild our bounded contexts diagram. We'll use Miro to empower ourselves (in small groups?) to create and move boxes. Are there opportunities to define cleaner boundaries between domains that enable better theme-specific autonomy? Are there terms and concepts that need updating, given what we know now? We'll briefly review a few domain-driven design (and team topology) principles and then dive right into a working session. If you're looking for diagramming inspiration, check out Got a wicked problem? First, tell me how you make toast. | ||
| Yoking UX and Tech (part deux) | Stacey Messier (Deactivated) Gabe Mulley (Deactivated) Nimisha Asthagiri (Deactivated) |
|
Related Resources
Requested Topics
Loosely Coupled beats DRY