Post

I think they are totally fine. Most of these queries are driven by specific view requirements and there is no point in littering contexts with functions like get_five_recent_nonshipped_ordera_by_user. Context should be for "serious" business logic.

In your example, the problem with calling multiple context functions that not all context functions are guaranteed to be composable within a transaction. They have effects like broadcasting over pubsub, or ordering requirements etc.

Wherever you do it you’ll have the same problem. If contexts can only make data changes in a way that transactionally composes, then they can’t be where your “business logic” is. I don’t see a difference in an application layer and a domain layer.

Not all applications have exactly one database for everything. Applications will integrate with external services etc. your user registration context function might do things like send emails and track analytics etc.

0 reposts0 likes

If you see contexts as something similar to DDD bounded contexts, then I agree, you should not do any cross context transactions, because all bets are off. In that case though it doesn't make sense to talk about an application or domain or infra layer, because a context contains potentially all 3

I don't use phoenix contexts like DDD bounded contexts. I see them as my domain layer and phoenix/web as the application layer. Depending on what kind of application I'm building, I'm pushing infra to the outside as well. In this specific case, cross domain context transactions can be done safely.

What is the difference between a domain layer and an application layer in your usage? I don’t typically see people use them as separate terms. They are typically synonyms.

I have never seen these terms being used interchangeably tbh. Domain layer is what your app really does, without infra (except maybe db, for practical reasons). Application layer runs domain in terms of current context, a Phoenix app, with background jobs, pubsub, API requests etc.

I define the domain layer as all the essential complexity you need in order to solve the business problems. Persistence is often accidental as it doesn't matter to the problem if it's solved with SQL, document storage or whatever.

Phoenix/web is by (my) definition not an application layer. It is a transport/interface layer. The logic of your application needs a unified interface, and should not be spread across a bunch of transport specific concepts like controllers, views, etc.