Most of your technical questions have already been answered but I feel the need to point out that the breakdown you showed might be a bit too micro (that depends on your needs of course). What I usually do is to have:

• data app, contains all data structures and all storage mechanisms’ drivers (PostgreSQL, Mnesia, Riak, Redis, Cassandra, what have you). Only schemata and migrations here, zero business logic if possible.
• domain app, or, lately I started naming that app with the name of the business itself. Contains every single piece of functionality to make your web app or API work – like the Phoenix contexts, more or less. Stuff like User.forgot_password or Cart.add_line_item or Order.finalize or Customers.send_marketing_emails goes here. It’s also a good idea to include your backend-agnostic authentication and authorization logic here, or, if that proves to be too big, refactor it out in a separate app (so far I found that to be an overkill though).
• web app, where I put everything needed for the website (or websites) of the business (Phoenix, Plug). Uses the functions in the domain app heavily, has no idea about the data storage mechanism at all. Should use functions like Cart.delete or Accounts.confirm_registration that change the database below and must never ever use a single Ecto-specific function or module (or whatever direct storage library). Might include authentication / authorization modules, as long as they are specific for the websites only.
• api app, where everything that exposes REST or GraphQL endpoints lives. Same as above: uses the domain app heavily, must have no idea about the data storage mechanism. API-specific authentication / authorization modules included.
• Lately I started adding another one in my projects: reports. Reports are a very weird beast and more often than not it’s best if they are just stored SQL procedures but when that’s not possible (namely when no dev wants to get their hands dirty) it pays really well to have all the ugly compromises and flaky performance optimizations in an entirely separate app so you can change stuff around without affecting your business logic or anything else.

One important caveat though: when using Ecto – like most projects do – having business logic wrapped in changeset functions is very valuable. Code like this:

params
|> cast(:your_association)
|> validate_required(...)
|> ensure_enough_stock(...)
|> apply_discounts(...)

…is very intuitive and the pipe-able nature of the changeset functions that usually live in your Ecto schema files makes validation and any extra requirements and data reshaping very convenient. In the end I left only validation in these (and they have to 100% mirror any database-level constraints which are encoded in the migrations; such duplication is one of the very few flaws of using Ecto) and moved the extra checks and processing into the business logic app – and I am calling them directly from the Ecto schema file changeset function.

That’s kind of ugly and creates a mutual dependency but so far hasn’t been an issue and still gives you a pretty strict separation of concerns.

In general: don’t let frameworks shape the project’s file structure for you. Think for yourself what makes sense, which apps/modules should be mutually dependent, which should be black boxes to the apps/modules that use them, and make the call. Elixir isn’t conservative in this regard; Phoenix just gives you sensible and easy to work with defaults but they are by no means mandatory. Trust in your own judgement!

My $0.02.

Dogmatic pursuit of “purity” for it’s own sake is rarely beneficial. However the idea behind Ecto’s schemas is that the shape of your data will likely closely mirror the shapes that already exist in your RDBMS’s datamodel - an idea that is rooted in the realm of CRUD applications.

However, as explored in the references in this post, in some “enterprise-y situations” the shape of the data used in the business context(s) may be some strange projection of the data as it actually exists within the RDBMS - at which point DB schema based structures and generic changeset functionality will be much less relevant - so the context defines the shape of the data that it needs to work with (not the repository).

Now if your business context has autonomy over its persisted data (i.e. data is not shared on the level of persistent storage) then there should be fewer reasons for divergent data shapes in persistent storage and the context.

Yes

That is the usual workflow in my experience

Yes, two separate apps would listen on two separate ports. There is some endpoint trickery you can do to allow them to share the same port, but the default would be like you suggested. So your Admin Web will listen on different port than Store Web, which might be good thing.

Yes, the whole runtime including processes and modules and all the code is shared. It all runs on the same VM if you use single node and do not do any clustering just yet, and communicates using function calls and local message passing (i.e. call/cast).

In your Repo app.

Newbie here (and to Elixir/Phoenix), so take with a grain of salt.

Unless I’m mistaken, in hard technical terms, I’m not sure I see a hard delimiter.

I don’t think anyone is saying there is a hard delimiter? Communication of intent is a huge part of software engineering. An umbrella project communicates (and reifies) the concept of “these are all part of the thing we are building, but they have been separated at the application level for reasons x, y, and z”.

So yes, granular code organization is nice, but the complexity is [edit: sometimes] warranted for this and reasons mentioned by others above.

The migrations and Ecto schemas are (hopelessly) tightly coupled with the underlying datamodel of the RDBMS. So as such they will always belong to the Ecto repo.

This means centralising validations and business logic in the Repo app

No. Most of the confusion arises from the desire to leverage the Ecto.Changeset functionality for validation within the context (app) in concert with the Ecto schema structs. From a DDD purist perspective that is an anti-pattern.

A DDD repository would typically unmarshal the RDBMS data into data types defined by the context - rather than the context depending on data types defined by the repository. You are free to implement a repository this way but at the cost of easily using Ecto.Changeset for validation within the context. (Inside the repository you are free to use Ecto.Changeset as much as you like - but any data entering or leaving the repository is supposed to be valid domain data).

I suspect that is one of the beefs that Dave Thomas may have with Ecto.