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.