Hexagonal Architecture and Clean Architecture
One of the things that changed my career as a software developer and changed my perspectiv...
For further actions, you may consider blocking this person and/or reporting abuse
Good article, however I think the use cases layer is not what implements the business logic, instead, what orchestrates the business logic, since this is the application layer equivalent in DDD. Business logic should be in your aggregates + domain services instead or if you don't use DDD in your BLL.
Great article!
One small critique: In the github example authentication is included as a a use-case and is tightly coupled to the idea of having a token. I don't believe this follows the principles described in the article, as there are other forms of authentication that use different forms of verification (certs for example) and as you say "use cases are the user actions". Logging in and logging out are user actions, but "authenticating" is not. Since authentication is only used by http middleware, and is a fairly low level detail of your system I believe this should be moved to the architecture layer and used directly by an adaptor.
I agree. The specific mechanism for authentication should be decoupled from the act of authenticating.
PS Don't forget authentication and authorisation are different things!
Super informative, would love some more on this topic !
Hi Dyralen. I am currently working on similar setup like the one from your repo and everything works perfect except the testing framework. I tried adding github.com/sindresorhus/got to your repo and run the test and issue is same as mine.
Just add
import got from 'got'to one the use cases and run the test, issue is:I know it is related to cjs vs ems module compatibility, but I couldn't solve the issue even if there is bunch of similar examples on the web, but none of it solved the problem. Do you know is there an easy fix for this? Thanks
Hi @pandzic1989
I've never worked with this library, however, after a quick search, I found that it doesn't work well with Jest.
I found the following closed issues in their repo, I recommend you take a look, it seems that there are some workarounds:
Nice blog, but I have some questions:
1- I think application layer come after infrastructure layer, not the inverse as you mentioned, Am I wrong ?
2- controllers and ui interfaces ect should only use use case implementations, which in their turn should use adapters implementations, Am I wrong ?
Domain > Application > Infrastructure. He said it right. Infrastructure is what we want to be the most abstracted from (think DB, other APIs, etc).
You're correct, you should be working directly with the implementations in the infrastructure layer, as the abstractions (ports) in the Domain and Application layers have to be implemented somewhere (adapters)
Hello
Thank you for this detailled article, so if I clearly understand, the clean architecture is hexagonal architecture which is more detailled about what are the domain layers (usecases and entities). Is that correct ?
Yes these architectures did a great job and helped a lot to bring a better systematic structure in our code bases. But they still bring some kind of complexity because of their functional dependencies between the layers. I found this article that explains the problem and how to solve it IODA Architecture-Decoupling concerns even more by getting rid of functional dependencies.
I would be interested in your feedback. - Btw, I am not the author, but I wish :D -
Really informative post, Thank you so much.