constructive debate Clean Architecture

[kiquenet]

to create a constructive debate @xurxodev twitter - xurxodev dot com says:

"I appreciate the creator's effort, which is why I will never leave a hate comment. But it wasn't a good implementation of Clean Architecture, no matter how many likes it got.

I saw many shortcomings and potential problems in the proposed solution.

I'll list a few.

Entities didn't protect their invariants.

Coupling between domain entities.

Application business rules and enterprise business rules were mixed up.

Everything was done with functions, even those with injected dependencies. This is a common problem for those who come from old JavaScript and switch to TypeScript.

And it had more limitations."

And another reference about Modularizing React Applications with Established UI Patterns by Juntao QIU
https://martinfowler.com/articles/modularizing-react-apps.html

[bespoyasov]

Entities didn't protect their invariants.

It might seem that way since “entities” here are just types (“anemic domain”), but, in the functional style, invariant protection falls onto the functions transforming the data (“domain services” if you will).

Since the project is a simplified illustration, the only use case that would need invariant protection is the “addProduct” function in the Cart module. It ensures the correctness of the cart's data structure and all the rules related to it.

(Other functionality that might need it could be order validation, cart emptying, discount application, etc. For those, the invariants would be ensured in the same way.)

Coupling between domain entities.

The relationship between entities is mentioned in several subsections of the “What Can Be Improved” section.

In short, yes, there is direct coupling between entities, and you could potentially decouple and isolate them and set up, say, communication exclusively through events, but there's a tradeoff between purity and the amount of infrastructural complexity involved.

In the case of not that big of a project (and especially targeted at the audience who is probably newer to the topic in general), I still believe some degree of coupling is acceptable if it lets me avoid unnecessary complications in code.

But in general, I agree that coupling is the root of many problems, and it should be watched closely.

Application business rules and enterprise business rules were mixed up.

The domain logic (“business rules”) is represented as pure data transformations on the domain types. (You can think of the as the “public API of the domain layer.”) Those rules are then used in the use case handlers that contain “application logic.”

(An exception could be “isDangerous” in the “addToCart” use case, which I overlooked, yes.)

Everything was done with functions, even those with injected dependencies. This is a common problem for those who come from old JavaScript and switch to TypeScript.

How is that a problem exactly?