One thing to notice is that having multiple “Product” schemas does not mean you need to have multiple tables in database!
Thanks to explicit schema declarations in ecto, you can have all of them refer to the same table in database and pick only the fields this context is interested in - leaving the others untouched. This also has the advantage of performing more optimal queries - retrieving only the columns we care for.

Database and application logic are separate - one doesn’t need to be coupled to another.

There is nothing that Phoenix can do that won’t require developers to think about their domain. If you don’t break into contexts, you will end-up in the situation you have today with a large web/models directory without any idea of what your application does (schemas reflect the database structure and not your application structure), how those models relate to each other and what are the proper boundaries.

However, if you break into too many contexts, or if you have contexts violating each other boundaries, you are also going to end-up with messy code anyway.

I believe questions such as where to put an embedded schema is exactly the kind of confusion that comes from having something such as web/models in the past. A schema is nothing more than Elixir module and a struct. An embedded schema as well. So you should structure them in the same way you would structure any other Elixir code.

A context is not made of schemas. A context is made of Elixir code, data structures or even processes.

Actually we specifically want to promote the opposite. You are misinterpreting the diagram in this case. The diagram is showing the context have independent Consumer and Product entities. So this is something we want to push folks towards and I could have covered better in the talk. For example, you’d have this dir structure:

|– lib
|–––– sales/
|––––––– consumer.ex # schema
|––––––– product.ex  # schema
|––––––– sales.ex    # context
|
|–––– support/
|––––––– consumer.ex # schema
|––––––– product.ex  # schema
|––––––– support.ex  #context

[quote=“mjadczak, post:3, topic:3908”]Extract the schemas to be “global”, so that they don’t exist in any bounded context. They have the base repo functionality needed by all contexts, and the two contexts call in and use them as needed. This seems to be a return to the Phoenix 1.2 approach, but perhaps it is warranted in these cases.
[/quote]

The opposite. You won’t have global schemas and stray Repo calls. Contexts will manage their own schemas, in different tables. When you run the generators, we namespace the schema tables under the context name, so you’d have "sales_products". Your Support.Product schema could have its own database table, or it could be an embedded schema that fetches the canonical %Sales.Product{} thru the bounded api, and then decorates it as a sales product as needed. Two separate database tables or the fetch and decorate approach will depend on your app. In either, you don’t have a global schema or breaking of the bounded api.