> The third thing can be a controller (true MVC), a presenter, a view-model, or, in the case of the article, operations and events. Well the article introduces

> The third thing can be a controller (true MVC), a presenter, a view-model, or, in the case of the article, operations and events. Well the article introduces weird new lingo which I don't think is all that great, but whatever. "operations+events" can be equaled to "business logic". Let's keep that separated from the controllers. I want to create a new user via an http request, but I also want to do the same via a console command and since I want to do both things with the same code but one of these shouldn't be returning http status codes, it makes sense this should live in a different layer. The whole events & operations separation in the article don't make sense to me. A "login attempt" as described in the article with a "login attempt" event being triggered by the view and that being picked by a decoupled "operation"? I don't see the value. If the operation needs to check privileges does it trigger an "check privileges" event, wait for another operation to complete? does that operation trigger another event to report the result? Wait a second... this sounds a lot like a convoluted Redux clone. Then you realize the only reason we are not doing Redux in the backend is because we are used to mutable state databases.