If you are a software developer, you probably have heard of different software architecture styles, such as clean architecture and hexagonal architecture. But what are they and how do they differ from each other? In this article, you will learn the main concepts and benefits of each style, as well as some examples and tips on how to apply them in your projects.
Clean architecture is a style that aims to achieve high levels of modularity, testability, and independence from frameworks and databases. It is based on the idea of separating the software into concentric layers, each with a specific responsibility and dependency rule. The innermost layer is the domain, which contains the business logic and entities. The outer layers are the application, which defines the use cases and interacts with the domain, the interface, which provides the input and output channels for the application, and the infrastructure, which implements the external dependencies such as databases and frameworks. By following this structure, you can isolate the core logic from the details and make your code more readable, maintainable, and adaptable.
Clean Architecture, proposed by Robert C. Martin, emphasizes the separation of concerns with concentric layers (Entities, Use Cases, Interface Adapters, and Frameworks) for flexibility and testability. Hexagonal Architecture, also known as Ports and Adapters, focuses on isolating core business logic from external dependencies, promoting a hexagonal shape with ports for interaction. While both prioritize maintainability and testability, Clean Architecture has distinct layers, and Hexagonal Architecture centers on ports for communication, allowing adapters to be plugged in.
Clean Architecture, introduced by Robert C. Martin, emphasizes separating concerns into layers with clear dependencies. It prioritizes dependency inversion and testability. On the other hand, Hexagonal Architecture, also known as Ports and Adapters, focuses on application ports for interactions and adapters for external systems. While Clean Architecture provides a broader guideline, Hexagonal Architecture specifically highlights the importance of isolating application logic from external dependencies through adapters, fostering flexibility and maintainability.
Hexagonal architecture is another style that focuses on decoupling the core logic from the external dependencies. It is based on the metaphor of a hexagon, where each side represents a port that can connect to an adapter. The ports are the interfaces that define the input and output operations for the core logic, which is located inside the hexagon. The adapters are the implementations that connect the ports to the external systems, such as databases, web services, or user interfaces. By using this approach, you can swap the adapters without affecting the core logic and test it independently from the infrastructure. You can also design your system as a network of hexagons, each with its own responsibility and communication protocol.
For example in messaging application, the core (hexagon) orchestrates message handling. Ports, interfaces defining crucial functionalities like message storage and notifications, include MessageRepository and NotificationService. Adapters implement these ports: DatabaseAdapter for storing messages and EmailNotificationAdapter for notifications. Such flexibility, a hallmark of hexagonal architecture, enhances maintainability and allows for efficient testing by substituting adapters with mocks during testing phases.
Both clean and hexagonal architectures share some common goals and principles, such as separating the concerns, enforcing the dependency inversion, and enabling the testability of the software. However, they also have some differences in terms of terminology, granularity, and flexibility. For example, clean architecture uses more specific names for the layers, such as domain and application, while hexagonal architecture uses more generic names, such as ports and adapters. Clean architecture also defines a strict hierarchy of dependencies, where the inner layers cannot depend on the outer layers, while hexagonal architecture allows more freedom in choosing the direction of the dependencies, as long as they are inverted. Moreover, clean architecture prescribes a fixed number of layers, while hexagonal architecture allows you to create as many hexagons as you need.
To illustrate the use of clean and hexagonal architectures in practice, let's consider a blog application. In clean architecture, the domain layer contains entities such as posts and comments, the application layer contains use cases such as creating and deleting posts, the interface layer contains controllers and presenters that handle requests and responses, and the infrastructure layer contains repositories and frameworks that interact with the database and web server. In hexagonal architecture, one or more hexagons are used depending on the complexity of the system. For example, a blog hexagon would contain core logic and ports for blog operations, while a database hexagon would contain an adapter for database access. The blog hexagon depends on the database hexagon but not vice versa. When applying these architectures to your project, start with the core logic and define interfaces for input and output operations. Choose suitable adapters for your system, implement them according to interfaces, use dependency injection to connect adapters to core logic, write unit tests for core logic and integration tests for adapters, and refactor code as new requirements or dependencies arise.
Clean and hexagonal architectures can offer various benefits and challenges for software development. Benefits include improved modularity and readability of code by separating concerns, increased testability and maintainability by isolating core logic from details, and enhanced adaptability and scalability by allowing for changes or replacements without affecting core logic. Challenges include more effort and discipline to design and implement layers or hexagons, complexity and overhead in code from added abstractions and interfaces, and incompatibility with some frameworks or tools that have their own conventions.
The initial setup of ports, adapters, and the hexagonal structure might seem overhead, particularly in smaller projects. While the initial investment may seem demanding, the dividends in enhanced flexibility and streamlined development make the hexagonal structure a strategic choice that aligns with project growth and evolving requirements.