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.
