I'm going to shamelessly take advantage of your being here with a question if that's ok. Do you have any recommendations for reading material that covers Phoenix as it's used today?
Back in the early 0.x days I read the Phoenix book, which was a great introduction to building an application and using Ecto, but trying to pick it up again recently I found that nothing really seems to cover using Contexts in the real world.
You probably have seen it already, but recent Phoenix docs have a section on contexts and what is their intended use case: https://hexdocs.pm/phoenix/contexts.html
The way I see it, context are just the public API to access your data model. Your Ecto schema is a piece of data, which in a functional language has no behaviour attached. The (business) logic to deal with this piece of data lives in the context. That's it.
It's nothing particular and specific about Ecto or Phoenix, it's just a good design practice that's applicable and recommended in any language.
What about access control? That's often directly tied into business logic, but it's so elegant and convenient to do it in the controllers or even the router using the pipelines. In fact a ton of the examples (I think even the Chris McCord Phoenix book) does exactly this, presumably for that reason.
However I did that with an app and haven't been very happy with it because while the bulk can easily be done in the router/controllers, there are things that are totally inappropriate to do there and so it ends up in the context. Then your logic is distributed and messy, which is awful. But putting all access control in the context also bloats and complicates a ton of otherwise very clean, elegant API functions. I try to keep the Repo query building code clean and separate but that often leads to inefficiencies (such as filtering fields in the caller instead of in the generated SQL, which is vastly preferred for obvious reasons).
Personally, here is what I do: if access control is part of the business model, then I put it in the context and, almost always, I raise. Otherwise, continue doing it in plugs. That's it!
For web apps, you should almost never be triggering these invalid access control state, because it means the UI is allowing users to do something they are not really supposed to do. If the user cannot delete a resource, then the button most likely shouldn't show up (or it should be disabled with a comment) etc.
Raising actually helps us find these bad UI paths too because I get an error I can act on.
Now let's say you do want to handle some of these errors. You have three options:
1. Continue raising and rescue in the controller (meh)
2. Continue raising and implement Plug.Exception for said exception so you control how they are shown to the user (great if they are still general exceptions)
3. Return {:ok, _} | {:error, ...} and handle it in the controller (or in the FallbackController for APIs)
Thanks :) I started reading the original DDD several years ago, but bailed out due to quite how dense it is, hopefully this summary will be a little more approachable.
Just to add to your comment: I've been running through the free LiveView course and it's been really great. I'm excited to finish it and continue with the pro one!
I have that book too and it's great. Will have to check out that specific section. I mostly used it to see examples and explanations of how to do things in the Ecto DSL (which it is great for).
Contexts are loosely (maybe a little more than loosely) based on the Bounded Context concept in Domain Driven Design. As a good introduction, I would recommend reading Domain-Driven Design Distilled by Vaughn Vernon. It's sort of like the Cole's Notes version of the full Domain Driven Design which is a monster of a book.
Back in the early 0.x days I read the Phoenix book, which was a great introduction to building an application and using Ecto, but trying to pick it up again recently I found that nothing really seems to cover using Contexts in the real world.