💻Application Architecture
Talks about the design principle followed to develop API's
Clean Architecture is a software design pattern that emphasizes separation of concerns, testability, and maintainability. It was first introduced by Robert C. Martin (Uncle Bob) in 2012 and has gained significant popularity in the software development community since then.
Clean Architecture in .NET Core is a way to organize the code of an application into separate layers, with clear boundaries and dependencies between them. The goal is to create a loosely coupled architecture that makes it easy to modify and maintain the code over time, without affecting other parts of the application.
The key components of Clean Architecture in .NET Core include:
Entities: These are the core business objects of the application, representing the data and logic of the domain.
Use Cases: These are the application-specific workflows that use the entities to accomplish specific tasks.
Interface Adapters: These are the adapters that connect the use cases to the outside world, including user interfaces, databases, and external APIs.
Frameworks and Drivers: These are the external components that provide the infrastructure for the application, such as the .NET Core runtime, web servers, and other third-party libraries.
The key benefits of using Clean Architecture in .NET Core include:
Separation of Concerns: The code is organized into separate layers, each with a clear responsibility, which makes it easier to modify and maintain over time.
Testability: The layers are loosely coupled, which makes it easier to write unit tests for the code.
Scalability: The architecture can scale to accommodate larger applications and complex workflows.
Maintainability: The architecture makes it easier to modify and maintain the code over time, without affecting other parts of the application.
Flexibility: The architecture is flexible and can accommodate changes in requirements, technology, and business needs over time.
Application Design
Entities:
These are the enterprise business objects of your application. These should not be affected by any change external to them, and these should be the most stable code within your application.
Use Cases:
Implement and encapsulate all of the business rules.
Interface Adapters:
Convert and present data to the use case and entity layers.
Frameworks and Drivers:
Contain any frameworks or tools you need to run your application.
The key concepts here are:
Any layer can only reference a layer below it and know nothing about what’s going on above. The use cases and entities are the heart of your application and should have a minimal set of external library dependencies.
Events
The events are sgregated based on two types of Domain Events and IntegrationEvents
Last updated