Just my perspective™:
For me, from a conceptual Comments context perspective there is no need for the Comments context to depend on either the Post or Movie context. There are things out there that want to be commented on but there is no reason for Comments to care what that is. It does care about keeping related comments together - so there is probably something like a comments_container that all related comments are associated with.
So in the simplest case Post and Movie context would have to handle comments_container_ids if they wish that the Comment context would handle comments for some of their posts or movies. Higher level contexts could be used to decouple them from the Comments context if that was necessary:
- Post Comments context which depends on Posts and Comments
- Movie Comments context which depends on Movies and Comments
Is it true that it doesn’t reduce separation with respect to the original documentation example?
The coupling that your are seeing comes primarily from the implementation choice of hosting the contexts on the same database. One context “accessing” another context’s table is a violation of that context’s autonomy - but it is also a trade-off to simply utilize that they are “living” in the same database so you don’t have to actually implement all that logic to enforce full separation right now. But there is the constant danger of simply devolving into an “integration database”.
Personally I find learning about contexts in this manner to be more difficult than if they were actually physically separated/distributed (which causes more work). The advantage of maintaining the boundaries inside a monolith is that it is easier to change the conceptual boundaries between contexts if they were suboptimal in the first place (which they often are). The disadvantage is that maintaining the established conceptual boundaries is an exercise in discipline and will because there usually is an “easier” way to deliver the next feature faster by disregarding the existing conceptual boundaries.
With that in mind I can see Dave Thomas’s point. The primary concern behind “Phoenix is not your application” should be not about contexts but about your application being a separate OTP application (from the Phoenix framework). Then when it gets to the point that your application needs to be broken into separate contexts, you can break out a separate OTP application, like a “User Profiles application” (and not necessarily as part of an umbrella project).
