Context separation or decoupling conventions and naming

Hi everyone,

This questions is created to establish the best way to deal with separation of big context like a blog in smaller pieces.

The main problem is that a Blog context can get very big if all the schemas go under one context.

I wanted to ask if the what is your opinion on the following scenario:

Article context with schema Article and a migration Articles

This would look something like this

YourApp.Article.Article when you will need to reference the schema which might be confusing

So I thought of making the naming more descriptive like this:


Question: Is there a better way to name this modules: context and schema for easy readability?


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


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
1 Like

This post helped me in trying to organize contexts…


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.

1 Like

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.