Backend and Frontend Split

Each self-contained system (SCS) would have its own (1) set of micro services, (2) GraphQL server and (3) micro frontend.  The responsibility of each SCS is determined via domain modeling (considering life-cycles and high-level use cases).  SCS' integrate at the frontend (via hyperlinks) whenever possible and synchronize data in the backend asynchronously.  From a distance, it may seem that SCS' are inefficient since they seem to duplicate data.  However, upon closer look, data duplication enables each phase in the life-cycle to optimize and evolve the data for its own needs.

High-level Bounded Contexts

Each DDD bounded context in this diagram maps to an independent SCS, as described above.  The responsibility of each context is described in edX DDD Bounded Contexts.

Authoring and Learning Split

The diagram below illustrates a possible break-up of contexts within Authoring and Learning.  Each "micro-context" could be its own microservice eventually, and its own repo or Django app in the near term.

See edX DDD Bounded Contexts for an explanation of each micro-context's responsibility.

Shared Features

There are some micro-contexts that are shared across Authoring and Learning.  For those, we imagine co-locating the code so the authoring-and-learning experiences are encapsulated within its own repo (as shown in the diagram below).  Depending on CAP requirements, a feature's combined authoring and learning experiences may execute in a single service or they may be deployed and executed independently in separate Authoring and Learning services.