The Evolution of Software Architecture.

Layered Architect?

Layered architecture is a design pattern that divides a software application into layers, each with a specific role and responsibility. The primary purpose is to segregate concerns, ensuring that changes in one layer minimally affect others. This separation makes the system more modular, maintainable, and easier to manage. It is the oldest architect in software development and frequently ever since it is first introduced used when application is not large enough or not divided into multiple modules.

Key Layers in Layered Architecture

• Presentation Layer: Role: Manages the user interface and user interactions. Components: UI components, frontend frameworks, and presentation logic. Examples: Web pages, desktop application UIs, mobile app interfaces. API Controller
• Business Logic Layer (or Domain Layer): Role: Contains core business logic and rules. Components: Domain models, business rules, validation logic. Examples: Calculations, decision-making processes, core business logic.
• Data Access Layer: Role: Manages data persistence and retrieval. Components: Repositories, data mappers, DAOs (Data Access Objects).

o?? Examples: Database access, ORM (Object-Relational Mapping) tools, file storage.

Benefits of Layered Architecture

• Modularity: Each layer can be developed, tested, and maintained independently, enhancing modularity.
• Scalability: Layers can be scaled independently, allowing for efficient resource utilization.
• Maintainability: Clear separation of concerns simplifies debugging, testing, and maintaining the system.
• Reusability: Components within a layer can be reused across different projects or other layers within the same project.

Clean Architecture

Clean Architecture is a software design philosophy that promotes the separation of software elements based on their roles and responsibilities. It ensures that the core business logic is independent of external concerns such as databases, frameworks, and user interfaces. This independence makes the system more flexible and easier to evolve over time.

Key Principles of Clean Architecture

1. Independence from Frameworks: The architecture does not depend on the existence of some library of feature-laden software. This allows you to use such frameworks as tools rather than relying on them.
2. Testability: The business rules can be tested without the UI, database, web server, or any other external element.
3. UI Independence: The UI can change easily, without changing the rest of the system.
4. Database Independence: You can swap out Oracle or SQL Server or any other database without changing the business rules.
5. Any External Agency Independence: In fact, your business rules simply don’t know anything at all about the outside world.

Layers in Clean Architecture

1. Entities: Role: Represent the core business logic and rules. Entities are the most general and high-level part of the system. Components: Domain objects, business rules. Examples: User entities, order entities, product entities., Student entities, Course entities etc.
2. Use Cases/Business/Application: Role: Contain the application-specific business rules and orchestrate the flow of data to and from the entities. Components: Interactors, use case implementations. Examples: User registration, order processing, product inventory management. Student Registration, Course Management etc.
3. Interface Adapters: Role: Convert data from the format most convenient for the use cases and entities to the format most convenient for external agents such as the database or web. Components: Controllers, presenters, gateways. Examples: REST controllers, data mappers, view models.
4. Frameworks and Drivers: Role: Contain frameworks and tools such as the database, web frameworks, and external services. This layer is where all the external dependencies reside. Components: Databases, web frameworks, UI frameworks, external services. Examples: Spring, Django, React, SQL databases, messaging systems.

Benefits of Clean Architecture

• Separation of Concerns: Each layer has a distinct responsibility, making the system more modular and easier to manage.
• Testability: Core business logic can be tested independently of external dependencies.
• Flexibility: The system can adapt to change more easily, allowing for swapping out technologies with minimal impact.
• Maintainability: Clear boundaries between layers lead to easier maintenance and updates.
• Reusability: Business logic can be reused across different projects or applications.

Onion Architecture?

Onion Architecture, introduced by Jeffrey Palermo, is an architectural pattern that emphasizes a clear separation of concerns and the use of dependency inversion to achieve a flexible and maintainable system. The core idea is to build the application around the domain model, with layers that form concentric circles around it. Each layer can only depend on layers more central to the core, ensuring that high-level business rules are not dependent on external details like databases or user interfaces.

Key Principles of Onion Architecture

1. Dependency Inversion: High-level modules should not depend on low-level modules. Both should depend on abstractions. Abstractions should not depend on details. Details should depend on abstractions.
2. Separation of Concerns: Different concerns are separated into different layers, making the system more modular and easier to manage.
3. Core-Centric: The core of the application contains the business logic and domain model, which are independent of external dependencies.

Layers in Onion Architecture

1. Domain Layer: Role: Contains the core business logic and domain entities. Components: Domain objects, value objects, entities, business rules. Examples: User, Order, Product entities with their respective business rules.
2. Application Services Layer: Role: Orchestrates the business logic and contains application-specific business rules. Components: Use cases, service interfaces. Examples: Use cases like CreateUser, ProcessOrder.
3. Interface Adapters Layer: Role: Translates data between the application and external agents like the UI, databases, and other services. Components: Controllers, presenters, repositories, gateways. Examples: REST controllers, data mappers, view models.
4. Infrastructure Layer: Role: Contains external dependencies such as databases, frameworks, and external services. Components: Database context, external APIs, UI frameworks. Examples: Entity Framework, SQL databases, web frameworks like ASP.NET Core.

Benefits of Onion Architecture

• Testability: Core business logic can be tested independently of external dependencies, improving the testability of the system.
• Flexibility: The system is more flexible to changes, allowing for easier swapping out of technologies.
• Maintainability: Clear separation of concerns leads to easier maintenance and updates.
• Dependency Management: Ensures that dependencies point inward towards the core, maintaining the integrity of business logic.

Hexagonal Architecture

Hexagonal Architecture is a design pattern that organizes the codebase into loosely coupled components, focusing on the core domain logic and separating it from the infrastructure and external systems. The architecture is visualized as a hexagon, with the core application in the center and ports and adapters on the periphery. This structure allows for flexible interaction with various external systems, such as databases, user interfaces, and external services, without affecting the core business logic.

Key Principles of Hexagonal Architecture

1. Separation of Concerns: Different concerns are separated into different layers, making the system more modular and easier to manage.
2. Decoupling: The core domain logic is decoupled from external systems, allowing for easier testing and maintenance.
3. Ports and Adapters: Ports define the entry points to the core logic, while adapters handle the interaction with external systems.
4. Testability: By isolating the core logic, the system becomes easier to test, as dependencies can be easily mocked or stubbed.

Structure of Hexagonal Architecture

1. Core Domain: Role: Contains the business logic and domain entities. Components: Domain objects, value objects, entities, and business rules. Examples: User, Order, Product entities with their respective business rules.
2. Ports: Role: Define the interfaces for interacting with the core domain. Components: Use cases, service interfaces, and event handlers. Examples: Interfaces for creating a user, processing an order, and managing inventory.
3. Adapters: Role: Implement the ports to interact with external systems. Components: Controllers, presenters, gateways, repositories, and external service clients. Examples: REST controllers, data mappers, view models, and database repositories.

Benefits of Hexagonal Architecture

• Flexibility: The system can easily adapt to changes in external systems or requirements, as the core logic is isolated from external dependencies.
• Testability: The core business logic can be tested independently of external systems, improving test coverage and reliability.
• Maintainability: Clear separation of concerns leads to easier maintenance and updates.
• Scalability: The architecture can scale horizontally by adding more adapters to handle different types of external interactions.
• Reusability: Core business logic can be reused across different projects or applications, as it is decoupled from specific implementations.

?