Although from reading these forums, it appears there’s no direct match between Phoenix’s contexts and DDD subdomains, many of us appear to use them similarly.
So when thinking of building an app that could scale easily, for example turn a context into its own app, I’m wondering if using a postgresql schema per context would be a way to prepare for that?
Are there any obvious gotchas to doing this eg can ecto do joins between postgres schemas?
I don’t see a direct mapping between having a certain business context / DDD subdomain (say, Users, Accounts, Orders etc.) and making a new small app out of that? Seems a bit arbitrary to me.
Thanks for your thoughts. Any specific reasons why not?
I was thinking of an OTP app that can be started/stopped for maintanence etc of each context you listed, even just as an admin app.
Putting aside the idea of using postgresql schema per context to migrate contexts to apps, what do you think of the idea of a schema per context?
There are other reasons I can think of for a schema per context eg if the number of users or order items grew huge, and each had a lot of tables - having the context as its own schema could allow moving it to its own db later easier - whether for its own app or not.
Another is avoiding table naming conflicts where multiple uses of the same table name makes sense across contexts.
The much better question IMO is “why yes?” – I mean, where did that need of yours emerge from? What need does it serve? What pain does it remove?
Bad idea. Often times when you deal with users for example, you have a User schema, a Profile schema and a bunch of others that are related to either their personal info or technical details helping with signing in.
Additionally, you’d definitely want to have a single context – Orders – when you deal with, a-hem, Order, LineItem, Cart etc.
You are over-fixating on problems that most teams I’ve ever been with are solving during a 10-minute chat.
I am trying to understand your goal here. From a practical / everyday programming work perspective your ideas are highly impractical and would impose extra work on a team of programmers. If this is for a self-learning project, OK, then I can understand that and we can chat on this from a different angle.
If You want to experiment with DDD, You might try to use umbrella application (mix phx.new koko --umbrella).
Then, each application You build might have it’s own db.
This is a micro-service approach, but it fits well with DDD.
I don’t think that making the correlation between DDD’s ‘Subdomains’ to Phoenix’s Contexts would be productive though. Phoenix’s Contexts work similarly to DDD’s ‘Bounded Contexts’ - although Chris Mccord made a presentation in the past explaining that this is not completely the purpose of Contexts, but could be if you want to (and dude, that disclaimer was really necessary).
It all boils down to app architecture and separation of concerns. This goes hand-in-hand with the expectation that you have right now to extract those contexts into multiple apps.
Contexts could work as ‘Subdomains’, but perhaps this is too much for most applications. If I’m working with a Domain that is so dense like this, I’d probably go straight to umbrella apps.
I always get a little suspicious when I read this type of question because this could be a sign of premature optimization. Also, the answers you’ll get here might not be what you expect as there’s no “one size fits all”… Do you have a specific problem you wanna solve by splitting your app like this? Because “scale easily” is very loose.
I’m asking that because if you don’t have this answer yet, perhaps you should hold assumptions about the Domain until those architectural needs reveal to be true.
Thanks. I’ve read a lot about umbrella apps in these forums and as closesly aligned as they are with my goals, it appears I can build a similar structure without their downsides.
Thanks, you’ve answered my question directly and cleared up my confusion.
© Copyright Elixir Forum | Terms | Privacy & Cookies
