Hi everyone,
Explanation:
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.
Problem:
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:
YouApp.ArticleContext.ArticleSchema
Question: Is there a better way to name this modules: context and schema for easy readability?
Thanks
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
...
1 Like
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.