Need help understanding Phoenix Contexts

You’re right, depending on the structure of your application it might make sense to draw different lines between the contexts. Since it is just a question of how you want to organize your application, it doesn’t really matter as long as the way you split your contexts is reasonable and understandable.

In the example you give, I would also say: It depends.
It depends on what the individual functions do. I. e.: Are Merchants also Users? Does Merchant use a different schema than User? Answering those questions might help you decide which functions belong to the same context and which don’t.

If Merchants are not Users (two different schema), does it still make sense to use option 2? In my mind, an Account is an account on a given app. The account could be of type User or Merchant.

Also check out these threads:

Since there will probably be additional Merchant functions in the future, Option 1 seems quite reasonable.
Since Users are also going to be their own thing, an additional Users context might also be a good idea.
And one more thing: Maybe consider renaming Users to Customers in order to be clearer when it comes to the wording.

it seems to me option 2 makes more sense because it will keep the context small. I am still unclear if we are suppose to keep our contexts from growing out of control with a huge amount of functions being placed in them? Anyone know the answer? @chrismccord

In rails i would abstract methods out of the model into small service objects, but I am still unclear what path we are recommended to take.

@sammkj - There is no “right” or “wrong” way to build your application. It ultimately comes down to whatever makes the most sense to you for your specific use case. You’re already on the right track by considering your application structure beforehand, a benefit of Phoenix’s contexts.

As to your question regarding the two options, the second option does look better. The contexts are simply a formality that encourage name-spacing and allow you to write decoupled code. By starting to develop with contexts in mind you’re setting yourself up for easier refactoring in the future. So, if you should choose option 1 or 2 today and in the future change your mind, you’ll be able to restructure the application without much hassle.

Nice talk

Contexts are basically features of your app.

Or practically, a business activity.

For example, in a FinTech company, one of it’s activities/services is offering loans to its clients.

Being a tech company, they want to automate it. So they ask the dev team to build a functionality to automatically send loans to clients.

LoanOffer now could be your context (translated from a business activity to a feature of their webapp)

In that activity you could guess now that the collaborator objects (Schemas) would be Loan, Client, Disbursement (for wiring the money), etc.

Another example is Facebook’s bookmarks. That is a feature right? In that context you have the Post itself, BookmarkGroup (videos, articles to watch later), etc. You get the point.

Also in scrum teams, you can also map the epics as being the contexts in your app. Cause epics are basically features of an app.

To be honest I feel this is putting to much into the idea of phoenix contexts. While phoenix had to come of with some form of contexts to be able to provide generators for them I feel the idea is much broader: Do not put business logic in your web layer, but create an plain elixir setup of modules with functions for it.

Not being more concrete allows for everyone doing phoenix to decide what makes most sense for their project. People can go a hardcode hexagonal arch. route with all sorts of layers and abstractions or have a single core context (when the business domain is not to complex). It however also has the downside of not being super obvious to beginners, as they cannot be guided to a one-size-fits-all solution and possibly need external/additional knowledge.