That’s it - that’s all there is to “contexts” in a Phoenix application - modules and functions defining public interface of your application. Anything more, any more philosophy you’re going to attach to this is entirely your choice.
From: Michał Muskała: Putting Contexts in Context
You may also interested in [this recent post by Chris McCord]
(How to chain controller actions or DB inserts in Phoenix? - #4 by chrismccord) and possibly this recent topic.
One thing to keep in mind is that the term context is overloaded in the ecosystem - which is probably contributing to some of the confusion. Domain Driven Design has the concept of bounded contexts and Phoenix contexts can be bounded contexts and for complex problem domains Phoenix contexts should strive to be bounded contexts.
But I suspect that the core motivation behind Phoenix contexts is far more elementary:
- Clear separation of the Web UI (or BFF API) from the problem domain logic - aka Phoenix is not your Application.
- Partitioning of the “problem domain logic” according the principles of high cohesion and low coupling.
Now “high cohesion, low coupling” sounds rather hand-wavy but the effects are evident during maintenance. For tightly coupled systems
A change in one module usually forces a ripple effect of changes in other modules.
which low (or loose) coupling generally avoids. Tight coupling usually happens when client code depends too much on a module’s implementation details.
The most common manifestation of low cohesion is that there is too much logic in a single module - it really should be separated into into a set of loosely coupled modules. Low cohesion modules are the proverbial Big Ball of Mud - huge API, difficult to reason about, and that module seems to need changes for every update.
