It's the next one in the pipeline! I'm still working on the research and scripting to make sure everything I say is backed by a respectable source and most probably I'll be able to record next week! Thank you for the feedback!
Thank you for the great explanation. I've learned both the Clean and Onion architectures during my bachelors, however two doubts always crossed my mind. 1- If the dependencies can only go inwards, how come the implementation of the repositories depend on the persistence that's placed on an even outer layer? 2- If we have multiple ways of reading configuration variables (ex: environment and Azure Keyvault), this may be implemented in an infrastructure layer. If the Application Layer or the Repository may access a variable on that Configuration, should it dependend on it? How may those access Configs?
Hi Pedro. It is very important to understand that these architectures leverage the concept of "inversion of control". I have a video for this ua-cam.com/video/SitKouWX3FU/v-deo.html However, let me try to explain it from another angle. Every time we want to decouple the core domain from something be it the database or a configuration, we leverage interfaces. The repository interface allows a core domain service class to include in its business logic the concept of persistence, i.e. we do acknowledge in the domain that we need to save and load data from "somewhere". The key aspect is that we don't want to make a hard decision on the where and how. We are not interested in the implementation details of how that interface takes shape as a concrete class. For all we know, it could be implemented by another team or a framework like Spring. What glues everything together is the IoC container (e.g. Spring) which at runtime (unless you use native compilation) will wire in the actual dependencies (i.e. it replaces the repository interface with a concrete class). This allows us to write all business logic without caring in the slightest on how it is implemented. We can also easily mock the repository for testing and speed up development. Hope this is clearer. Have a look at the IoC video and read about it online.
any Sim City players will appreciate the colour-coding of the layers. Infrastructure = Industrial, Domain = Commercial, Presentation = Residential. Makes sense as the users live in the presentation layer :)
I don't think you got the meaning of enterprise rules right. It's not about banking, and insurance polices, lol :p. An entity is application-agnostic. Let's consider the Product entity. It can be used not only by the e-shop application of the company, it can also be used by the Stock control application. Consider the Customer entity. It can be used by the e-shop application, and the Shipping and Labeling application. These classes describe business concepts and methods that are used by many applications, not just the one you developing. These types of classes are the entities. In contrast the use cases contain methods that are used by the one application you are developing. It doesn't make sense to have the Add-to-cart functionality in the shipping and labeling application. It only makes sense to have it in the e-shop application. So such methods will go to use-case classes in the application layer. They can't be re-used by other applications.
I used the banking, insurance, and company policies as an example of business logic you want to share across a group of applications within the context of an enterprise or large system. Business logic can be modeled and implemented with DDD as you mentioned (Entities, Aggregates, etc). However, I want to highlight that sharing entities between applications is not always a good call. In terms of DDD, you are dealing with a "shared-kernel" that couples different codebases and the teams behind it. That is why I feel the enforcement of enterprise level policies (e.g. insurance) is a much better example than sharing a Product entity between an e-shop and inventory management app. In those cases, I'd advice strongly against sharing entities between apps and just leverage proper "bounded contexts" and "contexts maps".
What do you prefer? The Clean Architecture or the Onion Architecture? Explain why!
Excellent video and UA-cam channel! Will be waiting for the video about hexagonal architecture
It's the next one in the pipeline! I'm still working on the research and scripting to make sure everything I say is backed by a respectable source and most probably I'll be able to record next week!
Thank you for the feedback!
Thank you for the great explanation. I've learned both the Clean and Onion architectures during my bachelors, however two doubts always crossed my mind.
1- If the dependencies can only go inwards, how come the implementation of the repositories depend on the persistence that's placed on an even outer layer?
2- If we have multiple ways of reading configuration variables (ex: environment and Azure Keyvault), this may be implemented in an infrastructure layer. If the Application Layer or the Repository may access a variable on that Configuration, should it dependend on it? How may those access Configs?
Hi Pedro. It is very important to understand that these architectures leverage the concept of "inversion of control".
I have a video for this ua-cam.com/video/SitKouWX3FU/v-deo.html
However, let me try to explain it from another angle. Every time we want to decouple the core domain from something be it the database or a configuration, we leverage interfaces.
The repository interface allows a core domain service class to include in its business logic the concept of persistence, i.e. we do acknowledge in the domain that we need to save and load data from "somewhere". The key aspect is that we don't want to make a hard decision on the where and how. We are not interested in the implementation details of how that interface takes shape as a concrete class. For all we know, it could be implemented by another team or a framework like Spring.
What glues everything together is the IoC container (e.g. Spring) which at runtime (unless you use native compilation) will wire in the actual dependencies (i.e. it replaces the repository interface with a concrete class). This allows us to write all business logic without caring in the slightest on how it is implemented. We can also easily mock the repository for testing and speed up development.
Hope this is clearer. Have a look at the IoC video and read about it online.
@@MarcoLenzo Thank you so much for the explanation. Will for sure have a look on the IoC video!
any Sim City players will appreciate the colour-coding of the layers. Infrastructure = Industrial, Domain = Commercial, Presentation = Residential. Makes sense as the users live in the presentation layer :)
Good one! 😆
very clear
Thank you 😊
great, thx
thank you :)
Always good to
Thank you
I don't think you got the meaning of enterprise rules right. It's not about banking, and insurance polices, lol :p.
An entity is application-agnostic. Let's consider the Product entity. It can be used not only by the e-shop application of the company, it can also be used by the Stock control application.
Consider the Customer entity. It can be used by the e-shop application, and the Shipping and Labeling application. These classes describe business concepts and methods that are used by many applications, not just the one you developing. These types of classes are the entities.
In contrast the use cases contain methods that are used by the one application you are developing. It doesn't make sense to have the Add-to-cart functionality in the shipping and labeling application. It only makes sense to have it in the e-shop application. So such methods will go to use-case classes in the application layer. They can't be re-used by other applications.
I used the banking, insurance, and company policies as an example of business logic you want to share across a group of applications within the context of an enterprise or large system.
Business logic can be modeled and implemented with DDD as you mentioned (Entities, Aggregates, etc).
However, I want to highlight that sharing entities between applications is not always a good call. In terms of DDD, you are dealing with a "shared-kernel" that couples different codebases and the teams behind it.
That is why I feel the enforcement of enterprise level policies (e.g. insurance) is a much better example than sharing a Product entity between an e-shop and inventory management app. In those cases, I'd advice strongly against sharing entities between apps and just leverage proper "bounded contexts" and "contexts maps".