[mattgreenrocks]

I want to re-read this and think about it more.

But one thing stuck out: I never liked most of the distillation of actions as clean architecture would advocate for, be they lambdas in class form (DepositAction) or interactors. I feel strongly that they are the right thing in describing business logic, however.

What did click for me is the conceit of a service, which the JVM world embraces. Services are plain old objects that have a method for each action you'd like to model. This is nicer than the aforementioned approaches because there is often common code to different actions. Like actions, services are the place where validation happens, persistence happens, and all of the interesting business logic. IO and orthogonal concerns are injected into them (via constructor), which lets you write tests about the core logic pretty easily.

What you get is the ability to reason about what happens without the incidental complexity of the web. Web handlers then boil down to decoding input, passing it to the service, examining the result of calling an action, and then outputting the appropriate data.

That's all they should've ever been doing. :)

[AtlasBarfed]

"Services" in the JVM, usually in the sense of Spring or some other service management framework, is just procedural code with a thing object instantiation layer which allows late binding invocations across services, which in complicated code turns out to be enormously useful:

- enable/disable/manage caching layers to procedure... uh... method calls

- play tricks with remote invocations that look like local ones

- enable advanced testing frameworks with mocked parameters and data connections

- enable/disable logging at runtime, and target specific services

- "aspects" to target various patterns of invocation and inject interceptors/decorators/etc to the procedure... uh... method call.

JVM service management OOP is a very different thing than domain/data object modeling OOP. JVM service management OOP is a slam dunk in terms of delivered value. In the referenced Alan Kay bullet points, it is mostly extreme late binding, and kind-of message passing that delivers tremendous value.

Data modeling OOP and GUI framework OOP is the old dog is-a animal, but is-a pet and all that headache. Because Java's behavioral compositional model is basically single inheritance (yeah, there's interfaces if you want to copy-paste or write your own delegates), it is fundamentally limited. That is the OOP that has squarely and properly been questioned over the last 10 years.