About dependency of Entity from Gateway in Clean Architecture

Question

I have a question about Gateway to Entity dependency in Clean Architecture. I think that the following concentric figures are often introduced as clean architecture.

In the figure above, Gateway does not look directly at the Entity. However, there is another famous illustration of Clean Architecture. (2nd figure) When it comes to actually creating a class, I think it will have the following structure.

Looking at this, the DataAccessInterface, which has the role of Gateway, refers to the Entity. I think that the gateway in the first figure violates the rule that it does not refer to Entity. What does this mean? ??

Also, if Gateway refers to Entity, if you want to return your own error from Gateway, you need to put your own error definition in Entity. The original error is an error specific to the application, and I feel that it does not match the domain logic. Is such a definition method correct for clean architecture? ??

Answer 1

The most important thing is that dependencies point inwards. That means, that the layer containing the most precious business logic should not have dependencies to the outer layers.

If the Gateway works directly with some entity from the domain (or logic layer, in the diagram you're referencing named "Entities") and has a good reason to directly access it and bypass the application layer altogether, this can be a valid and pragmatic decision.

Sometimes there is no complex application logic that might justify introducing the indirection in the application layer. However, it is good to keep an eye on such decisions and make sure the application is being refactored when the time comes that an application service that translates from the Gateway to the entity layer is making sense. Just make sure you work with what is provided by the entity (business) layer to fit the business logic and invariants. As soon as you would have to change something in your entity just to fit some needs of the outer layers this is a smell and some indirection (such as the application layer in between translating between the two layers) is definitely needed.

Concerning the error it is a similar decision. As long as the entity (in the domain logic layer) does only have to know about errors that are meaningful from the business perspective it could be to okay directly use that error if it fits the needs of the "outside" world the Gateway is talking to

So again, it is a decision depending on your situation. Just keep in mind that it is important to NOT extend the entities in the business/domain logic layer just to fit any infrastructure related needs, such as providing different structuring of error information or additional technical details that have no meaning in the business world.