Hello, I’m curious about the reasoning behind prefixing the table names when creating a new resource via context generator. What would be the recommendation in the case that someone does what the docs refer to when mentioning that a resource may be a part of different contexts:
Note a resource may also be split over distinct contexts (such as Accounts.User and Payments.User).
What would be the recommended table name here? accounts_users or payments_users or something else?
I understand that you can change it, but being part of a generator somewhat implies that they want to drive the point that we should be thinking about things in terms of contexts and I’m curious what folks have to say about this.
Personally, I would just name my table users, but I’d like to hear from others and get a sense of the conversion.
5 Likes
I is an opinionated decision of framework authors. The reasoning is that you keep your bounded contexts separated this way, also on database level. But you do not have to do it, I certainly don’t and do not feel bad about it 
Sounds like we can create a poll 
By the way, I don’t add context prefix to table names, either.
1 Like
Wouldn’t it be super annoying to keep a table for each context synced? At least I rather deal with NULLs on non-shared columns than update shared columns for each table.
If you are using Postgres you can use table inheritance.
I too name my tables without prefixes. I believe that contexts should not permeate into the database. So, I always use the --table option while generating models. One of us should send a PR which allows adding a --drop-table-prefix to the generator config (and adding it to the switches).
2 Likes
I’d second the general pattern of not having the context prefix on database column, but I still have some different schemas for each context… my understanding is this is half the purpose of contexts/ schemas as opposed to models, as each schema uses only the columns relevant to that context, but it doesn’t stop other contexts from having many of the same columns or having relations between columns… in the accounts_users and payments_users example, I’d imagine its still just a users table, but the payment context might have a credit_card_id foreign relation there, and the accounts section might have a profile_id, but payments doesn’t care about a profile and accounts doesn’t care about a credit card, so they don’t bother having in their seperate schemas, and therefore a) they can’t be used from there carelessly, and b) you save pulling that data from the DB on each load since the schema doesn’t know about it, so don’t have to select specific columns to get the savings… and if one table gets a ton of columns from a ton of different contexts, it will be pretty easy to avoid seeing the impact and bloat of that in any one context.
