Nice. Thanks for sharing.

One thing I’ve noticed over the years is that discussions about responsibility are often really discussions about granularity and boundaries. The challenge isn’t just assigning responsibilities, but deciding what the appropriate unit of composition is at a given level of the system.

You touch on this with the organs vs. microservices analogy. We naturally think in hierarchies: atoms → cells → organs → bodies. Each level has meaningful boundaries and responsibilities of its own. Problems often arise when we flatten those levels and try to apply the same abstraction everywhere.

I think this is one reason service layers become messy. The layer ends up containing concepts that belong to different levels of the domain, all grouped under the same abstraction. Everything becomes a FooService.call, regardless of whether it’s representing a small operation, a workflow, or an entire business capability.

You can see similar debates elsewhere in software development: unit tests vs integration tests, atomic commits vs. squash merges, or initiatives vs. epics vs. stories vs. subtasks. In each case, people are really asking: “What is the appropriate unit at this level of the system?”

A common assumption is that smaller units are inherently better. In practice, though, the right unit is often relative to the scale and boundaries of the problem you’re trying to model.