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.

0 reposts1 like

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.