Of course they are still coupled, and of course in many cases you will deploy them at the same time. It’s nice to have functionality, however, to re-design a registration page as new umbrella app, deploy it to running system, feature toggle it or A/B test and get rid of it if works worse than previous one. It’s the stuff like this that makes this umbrealla-based architecture extremely appealing to me.
When it comes to contexts, it all seem to boil down to generators and what is namespaced in the context module and what not. I think good software developer would namespace their code in similar manner anyway. However, I do not see the reason to namespace modules that I consider part of application infrastructure and those are for me:
-
Controllers, views and templates. I’m fine if these are flat layered under “Web” or whatever. It’s just the glue that takes parameters, forwards request to services layers and renders response.
-
Database-mapped Ecto modules. I generally namespace it under “Db” or “QueryDb”, “WriteDb” etc. This is also just the glue that allows one to read and write data to database.
In this approach you have clear focus on what is core of your application and what not. UI is important but it’s not your business logic. Database is important but it’s not your application either.
I do not think that one should treat “Comment” as a database-mapped struct namespaced in context “BlogPosts”, because it’s external data, stored in table “comments”, in some external database “Db”. If we really kept that data internally, private to context - then yeah, it makes sense. But we don’t do that, most likely.
The reason for 1) not making sense for me is that UI will most likely diverge from and cross the boundaries of contexts anyway. The reason for 2) is actually the same, if you have single database, the queries to this database will cross contexts anyway.
