Decorators For Inter-Layer Communication

I am trying to implement a new architectural approach for inter-layer communication by using abstract models and decorators.

Conventionally, when we design the layers of a monolithic application, we would have a application(controller) layer, a domain(business) layer and an infrastructure(persistence) layer. Those layers communicates with each other by a concrete model definition, that when being read from a database, navigates through a repository, then to a service and finally to a controller that dispatches it out to a client.

That said, let's get to the point...

Normally the infrastructure model must not be the same as the business model which also must not be the same as the UI model. The infrastructure model may concern only with it's destination repository strucutre, the domain layer may concern only with business operations, and the UI layer must only be concerned with it's clients and data read/input.

All those layers must "understand" an abstraction of each other, or even implement bi-directional value mapping(or DTOs), in order to communicate between them. Mapping/DTO is a bad approach because we would have objects copies in memory.

So, here is what I'm trying to do: Separate layers by using decorators for communication.

In that approach, we would have abstract components and it's decorators on a shared module, and each layer would have it's own decorator.

Eg.:

• AbstractFoo is an abstraction;
• FooDecorator implements AbstractFoo and also wraps an AbstractFoo;
• FooEntity is an infrastructure model that implements FooDecorator and handle persistence stuff
• FooBusiness is a business model that implements FooEntity decorator and handle business stuff
• FooView is a controller model that implements FooBusiness decorator and handle UI fields, encoding and etc...

With that approach we could:

• Have only 1 object in memory holding Foo information, but every layer "minds it's own business".
• Separate the layers in different modules, so the business only imports the infra, and the app layer only imports the business.
• We could distribute stubs for dumb logics without giving away our domain, like a shopping-cart service that must only know the summary of a Product, but not the domain object itself.
• We could have different teams working in different layers of the application without conflict.

Here's an example on paper:

Sketch

So...what I ask is for suggestion, tips and some opinions if it's a good approach.