Also check out these threads:

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.

@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.