Context separation or decoupling conventions and naming

I do something similar for the blog part of my app, though your contexts are sliced thinner than mine.

MyApp.Blogging.Articles.Article

Blogging is the context
Articles is the sub-context
Article is the schema

All of the functions related to articles are in Articles.

The Blogging context then delegates to those functions…

alias MyApp.Blogging.Articles

defdelegate list_articles, to: Articles
defdelegate get_article!(id), to: Articles
...

This post helped me in trying to organize contexts… https://devonestes.herokuapp.com/a-proposal-for-context-rules

For the question of where to separate things out I usually think about: Which things change together or independently (in the future). Which changes to a part of the system require changes to another part of the system (coupling). It a context is one cohesive part of your domain, but you feel it’s to big, first try to separate stuff within the context, before you move things out to their own contexts and them effectively becoming a part of your whole apps api.

Interesting naming and very useful to use defdelegate to each context.

Thanks @baldwindavid for sharing your solution

Thanks @baldwindavid for sharing the article.

Thanks @LostKobrakai for sharing your thought process and also the future considerations to take into account when separating contexts.