Post

ecto queries in liveviews and controllers? discuss. 🍿 #ElixirLang #phoenix #code

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.

I actually posted about this recently, just not here. genserver.social/notice/Ap4or...

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.

So maybe contexts should not do that? Or wrap everything with an outbox pattern. In the end it really is the question if the context is part of the domain layer or application layer, I think.

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.

I'm not sure I understand what you're saying. Why is business logic coupled with doing other things than transactional composition?

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.

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 see what you're saying, and I can see *a* distinction between the two, but I don't think that is how "Application Layer" is typically used. Regardless of how it's typically used, thats not how I use it. The idea that you have some kind of stateless domain layer and that background jobs or pubsub

is a concern of a particular consumer doesn't really track for me in reality. What happens in the background etc. is part of your domain logic. What elements of your system talk to each other is as well. I know that things out there try to model these things in a sort of "pure" fashion but I don't

think its really all that practical. You have to have tons of mapping layers between some concept of a thing and the implementation of the thing. Like if you have an event oriented architecture and your app wants to emit a notification and you want to make it in some way agnostic to the medium

over various interfaces but which encapsulate a running system capable of performing all of your business operations etc, and clients which may do things like provide user interfaces over that logic, or may call into it for their own purposes like external APIs etc.

I wouldn't say the domain layer is stateless. In a typical setup - the domain layer defines interfaces that the infrastructure layer has to implement. The domain uses the interfaces and so has access to state.

In elixir this is definitely a pattern that I haven't seen yet, but I've implemented it myself for one specific application. For others I just went with the "default" way of doing things.

The problem is that it’s all way too entangled to try to separate layers that way. It’s hard to explain this, but contracts of calls are not enough to allow integrations to shift. For example, one API uses idempotency keys to prevent duplicate request handling and another uses