Clean Architecture - An Introduction | Dan Does Code #64
Replies: 8 comments 12 replies
-
Good article Dan. I like your conclusion about software becoming more testable and maintainable using patterns like this as that is where I spend most of my time (legacy code!) |
Beta Was this translation helpful? Give feedback.
-
Cheers Dave! I'm really digging clean architecture with CQRS and MediatR. I have a new project starting where I will be using this pattern in full force. In projects I've previously worked on that use N-Tier, the 'services' end up becoming dumping grounds for all sorts of logic. I'm hoping CQRS and clean separation will help to solve this. Psyched to see the result. |
Beta Was this translation helpful? Give feedback.
-
https://app.pluralsight.com... Vladimir Khorikov's courses on Pluralsight seem to be architecting along the same lines as you are, and this new one using EF Core and CQRS looks interesting too. |
Beta Was this translation helpful? Give feedback.
-
I did a couple of pluralsight courses during free april around DDD and Clean Architecture. Vladimir's courses were on my list also, but ran out of time. |
Beta Was this translation helpful? Give feedback.
-
Nice. Lots of talk on https://www.reddit.com/r/do... on MediatR and EF Core at the moment. |
Beta Was this translation helpful? Give feedback.
-
Thank you.. very good article |
Beta Was this translation helpful? Give feedback.
-
Cheers mate |
Beta Was this translation helpful? Give feedback.
-
Good article, But I have one important question, If we are using DDD the repository interface definitions must be in Domain layer otherwise you can't use Domain services in aggregates. Am I wrong? |
Beta Was this translation helpful? Give feedback.
-
Hey Rasul. I'm no expert on DDD, but what you are saying makes sense. You could have the repository interfaces in the Domain layer, but keep the implementation in Infrastructure, so that the domain is still persistence ignorant. |
Beta Was this translation helpful? Give feedback.
-
thanks for great article !! I have one question though - benefits you called out in context of clean architecture can be achieved in layered architecture with DI implementation, isn't ? |
Beta Was this translation helpful? Give feedback.
-
Thanks for the feedback! Yes you can achieve some of the benefits if you use the layered approach and DI. It would really depend on which layers you have in your application and the depencies between them. You will be missing out on some advantages of you dont use MediatR though. |
Beta Was this translation helpful? Give feedback.
-
a clean article for clean architecture. 👏 |
Beta Was this translation helpful? Give feedback.
-
Cheers for the feedback! |
Beta Was this translation helpful? Give feedback.
-
Nice one :) |
Beta Was this translation helpful? Give feedback.
-
|
Hello. Thank you for the article. Can you please elaborate on this point: "The Domain Layer could be included in the Application Layer, but if you are using an ORM like entity framework, the Infrastructure Layer will need to reference the domain models, in which case it's better to split out into a separate layer." |
Beta Was this translation helpful? Give feedback.
-
|
Hi @Jyuart. My view on this has changed slightly since writing the article. Some CA solutions have a 'Core' Layer, which is a combination of both Domain and Application. I think that is fine for trivial applications, but my preference is to keep Domain and Application in separate layers. The benefit there is that we could share our Domain with multiple applications which is not possible when these are combined. You are right, the use of an ORM or any other persistence technique should not influence where our Domain is stored. One major point of a CA architecture is that the Domain should be persistence ignorant. Thanks for the comment. |
Beta Was this translation helpful? Give feedback.
-
|
Hi Dan, thank you for this article. I have a question regarding the Application Layer services.
I understand that it should reference outside layers or concrete implementations of the persistence layers. My question is. Should it reference other "application layer services" as well, if no then why? I'm in favor of NO but I'm looking for practical reasons for this. Thanks. |
Beta Was this translation helpful? Give feedback.
-
If we're talking about the Application Layer, I think you mean "it should NOT" reference concrete implementations of the persistence layers.
I'm not sure if I understand here. Are you asking if Services in the Application Layer, can refernces other Services in the Application Layer? Please correct me if I haven't understood you properly. 🙂 |
Beta Was this translation helpful? Give feedback.
-
Yes. Sorry that was a typo but thanks for catching that.
Yes. Services in the Application Layer referencing other Services in the Application Layer (as dependencies). What do you think in your opinion? This was not specifically mentioned in your article. I'm in favor of NO myself and I'm doing a research on why not. Thanks Again. |
Beta Was this translation helpful? Give feedback.
-
Generally I like to use the CQRS pattern in my Application layer. This results in having a separate 'handler' for each command or query. Each handle is also responsible for the transaction for each request (i.e. either everything or nothing gets saved). Due to this transaction, it gets messy if handlers try to reference each other. Therefore, I have a rule that they can't. If you're using services in the same capacity, then I would suggest the same rules apply. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Clean Architecture - An Introduction
https://www.dandoescode.com/blog/clean-architecture-an-introduction/
Beta Was this translation helpful? Give feedback.
All reactions