News for hackers. Stuff that matters.
Re:Message-Oriented Programming (2017) by Ace17 on Tuesday March 20, 2018 @02:32AM (#16626394)
I think this is a very interesting direction.

Classic programming generally doesn't impose restrictions about which direction the data flow is. By default, methods take value from their callers as input, and return values to their callers as output.

An "notification"/"fire-and-forget" interface allowing no data to go back to the caller (no return value, no "output parameter", no visible change to the program state, from the caller's POV) has very interesting characteristics (Like being trivially mockable).

Re:Message-Oriented Programming (2017) by SimonKinds on Tuesday March 20, 2018 @03:16AM (#16626530)
I believe this is what Command Query Responsibility Segregation (CQRS) is all about. By having one object handling writes, and another for reads, things are easier to reason about among other benefits. An event bus is kind of required in this kind of architecture if the view that's reading wants to stay updated, as it may no longer access a return value.

Source: https://martinfowler.com/bliki/CQRS.html

Re:Message-Oriented Programming (2017) by leoc on Tuesday March 20, 2018 @03:37PM (#16631816)
I think Fowler would describe the model in the article as more like "Event-carried State Transfer": https://www.youtube.com/watch?v=STKCRSUsyP0 .