These two days I have been reading Phoenix 1.3. Learnt that the new generator by default puts schema inside contexts. After reading the post from @michalmuskala Putting Contexts in Context, I agree having context as module is a good idea. But is it worthy to have contextual schema?

I guess the benefit of putting schema inside context is similar to rom-rb which will have fewer couplings between database table and model schema. E.g. model schema can be just a partial of database table schema. And the disadvantage will be harder to define cross-context associations.

The best practice to define cross-context associations either is still in a grey area or will never exist (because YMMV). According to Putting Contexts in Context, the approaches to define cross-context associations will be:

1. Don’t use join at all. “So, for example, instead of having an association, you’d only store the id. You can still access the data using the public interface of the other context.”
   Cons: N+1 queries and worse performance.

2. “Having schema in each context reading from the same table (each having access to mostly different fields)”
   Cons: fragmented schema and no single source of truth (sounds like how spaghetti begins).

3. “Having multiple tables that use the same primary key value (so you don’t have to keep a separate foreign key around).”
   Cons: dirty hack around.

Since performance is one of the major reasons that makes me choose Elixir & Phoenix, I will opt out option 1. And I personally hate option 3. So last standing option 2.

Therefore to me, contextual schema VS non-contextual schema is a tradeoff of more couplings between database table and model schema VS fragmented schema and no single source of truth. I personally hate fragmented schema and no single source of truth more. Hence, an out-of-context schema structure (or database-coupled schema structure) might be more handy for my general projects.

For example, if I am making a car dealer app, Phoenix 1.3 will give me contextual schema structure like this:

Contextual schema example

CarDealerApp
└── contexts
    ├── admin-edit-product
    │   ├── interfaces
    │   │   └── update-product
    │   └── schema
    │       └── product
    ├── explore-product-plans
    │   ├── interfaces
    │   │   └── list-plans
    │   └── schema
    │       ├── plan
    │       ├── product
    │       └── user
    ├── explore-products
    │   ├── interfaces
    │   │   ├── list-products
    │   │   └── show-product
    │   └── schema
    │       ├── product
    │       └── user
    ├── get-product-plan-quote
    │   ├── interfaces
    │   │   └── create-quote
    │   └── schema
    │       ├── plan
    │       ├── product
    │       ├── quote
    │       └── user
    └── registration
        ├── interfaces
        │   └── create-user
        └── schema
            └── user

In contrast, the out-of-context schema I propose will look like this:

Out-of-context schema example

CarDealerApp
├── contexts
│   ├── admin-edit-product
│   │   ├── changesets
│   │   │   └── to-update-product
│   │   └── interfaces
│   │       └── update-product
│   ├── explore-product-plans
│   │   └── interfaces
│   │       └── list-plans
│   ├── explore-products
│   │   └── interfaces
│   │       ├── list-products
│   │       └── show-product
│   ├── get-product-plan-quote
│   │   ├── changesets
│   │   │   └── to-create-quote
│   │   └── interfaces
│   │       └── create-quote
│   └── registration
│       ├── changesets
│       │   └── to-create-user
│       └── interfaces
│           └── create-user
├── schema
│   ├── plan
│   ├── product
│   ├── quote
│   └── user
└── validations
    ├── plan_must_be_avaliable_in_region
    ├── product_must_be_active
    ├── quote_expiry_date_must_be_before_plan_expiry_date
    └── user_must_be_vip

Basically, I would still keep changesets contextual because it’s very common that contexts require different fields, etc. On the other hand, I would abstract the specific validations out of context since often they will be shared across contexts. validations folder structure can be either flat or grouped by schema name, it can make sense in both ways and does not really matter.

What do you think?