[znort_]

> They focus on objects when we should focus on morphisms.

if you're building real systems you should focus on both.

> Coupling as Hom-Set Size ... The second interface is easier to implement, test, mock, and evolve.

i would doubt that. this just hides the complexity of multiple interfaces inside single, more general interfaces. if those "arrows" actually exist you will have to test and evolve them anyway, and adding some extra classification level does little apart from adding complexity.

> Pipelines ... Why This Matters ... Testability: Each morphism can be tested independently

i agree ... and this just contradicts the previous point about hom-set size.

> The arrows are what matter.

everything matters. i'm aware of the benefits and appeal of category theory, but i don't see the need to shoehorn it into everything, this just seems an example of evangelization of extremes. iow: if your only tool is a hammer everything looks like a nail, and that's not conducing to good design.

[karmakaze]

> “We need a User Service”

This is an XY problem statement. We need Y to do X (the following):

> “We need these operations on user data: create, read, update, delete, authenticate, authorize”

[znort_]

> This is an XY problem statement

no, it isn't. we need both, they're different aspects of the same thing. hyperfocusing on the former and disregarding the latter is just as bad as doing the inverse, and is exactly the problem i was describing.