[yawaramin]

I think the author is basically describing the Naked Objects pattern, i.e. deriving the full stack of your application, from storage layer, to internal logic layer, to presentation layer, from one single domain layer.

The problem with this pattern is that it makes the application brittle and difficult to change. If you need to change something in the UI layer, it will likely ripple down through business logic layer into the storage layer. If you make a change in the storage layer, you could inadvertently end up changing your user-facing API and breaking something for them.

The point of all the boilerplate we have today is to make the systems modular and able to be evolved independently of each other. Sure, if you don't need that much modularity, then by all means simplify. But I hope you're at least using a statically-typed language, because chances are you will need to refactor in future and it would really suck to rely on only unit test coverage while making wide-ranging architectural changes across the codebase.

[HelloNurse]

> If you need to change something in the UI layer, it will likely ripple down through business logic layer into the storage layer. If you make a change in the storage layer, you could inadvertently end up changing your user-facing API and breaking something for them.

This sort of "rippling" should normally result from poorly thought out and excessively casual changes layered over previous bad design.

Changes coming from the UI layer should normally be new and altered ways to search and modify the same entities, with no changes to the core model and its storage.

Changes from the storage layer are unlikely (e.g. new indices or adjusted datatypes in a database) and should be handled by some persistence abstraction, with a very limited impact in the business logic and completely invisible and irrelevant for the UI layer.

[pyrale]

> If you make a change in the storage layer, you could inadvertently end up changing your user-facing API and breaking something for them.

Here is the thing though: if you have a proper type system, this breakage will happen during compilation. That's a good opportunity to understand what's up there without impact.

So it actually becomes a benefit to be able to move things at one end and be able to see the effects at the other end, not just a protection or a requirement.

[tragomaskhalos]

Naked Objects is a fascinating idea that seems to have mostly disappeared from view. From my reading on it the UI basically falls out of the domain model fully formed, and that was what end users work with exclusively. I imagine that might seem too simultaneously worrying and limiting for it to gain traction in the conservative corporate sphere.

[asplake]

That was my approach too for a long time. Thankfully I had at my disposal something untypically (for its era) capable of modelling interestingly rich structures (capable of modelling syntaxes in fact), but still it’s a bit of an antipattern if taken to the extreme.

If you’re not careful, you end up with things like CRUD apps, leaving a lot of work to the user. To break away from this, you need to start thinking in use cases, user journeys, and so on. Not that data isn’t vitally important, but it’s not everything either.