Harmonizing SOLID, Clean Code, and Domain-Driven Design: Crafting Software Boilerplate Part II.

In this article by Mohamad Shatnawi we will continue our journey in the SOLID Principle, Clean Code and DDD.

1. Core Module?

The Core module serves as the foundational bedrock of our application. It encapsulates essential components that are instrumental for the smooth operation and interaction of various modules. In this module, we find four key components: Account, Events, Handlers (Query and Command Handlers), and Specifications.?

These components within the Core module work in harmony to provide a solid foundation for our application, fostering reusability, maintainability, and adherence to clean code principles. In the following sections, we will delve deeper into each component, exploring their functionalities and best practices for implementation.

2. Account?

The Account component encapsulates a common interface that has shared properties of the system’s accounts. The UML diagram for this component illustrates account interface. Different properties can be used depending on the system needs.?

?

3. Events?

Events are central to our application's ability to respond to changes and trigger actions. The Events component manages domain/application events, enabling decoupled communication between different parts of the application. The UML diagram showcases event classes, listeners, and their relationships.?

Domain-Driven Design (DDD) Harmony

The Events component demonstrates a clear alignment with DDD principles, particularly in the way it handles domain events. The use of the ‘IEvent’ interface as a representation of domain events reflects the DDD concept of capturing real-world occurrences within the software. This approach ensures that events are modeled as first-class citizens of the domain, making it easier to maintain a shared understanding of the system's behavior.?

Furthermore, the use of the ‘EventDispatcher’ to manage event listeners and dispatch events adheres to DDD's emphasis on decoupled communication between different parts of the application. This decoupling ensures that domain logic remains isolated and that various parts of the system can react to events independently, promoting flexibility and scalability.?

SOLID Principles at Play?

Following is the breakdown of the SOLID Principles are used in the Events management architecture.?

• Single Responsibility Principle (SRP): The components within the "Events" module have well-defined responsibilities. The ‘IEvent’ interface represents an event's structure, adhering to the SRP's guideline of one reason to change. The ‘EventDispatcher’ focuses on the responsibility of resolving and dispatching events to listeners, and the generic listener interfaces (‘IAsyncEventListener’ and ‘IEventListener’) cater to handling events asynchronously and synchronously, respectively. Each component has a single, well-defined role, aligning with the SRP.?
• Open/Closed Principle (OCP): The architecture allows for easy extension without modification. New event listeners can be added without changing existing code. This adherence to the OCP promotes maintainability and prevents unintentional side effects.?
• Liskov Substitution Principle (LSP): While not explicitly mentioned, the component's design implies that all event listeners (whether asynchronous or synchronous) can be substituted for their base type (‘IEventListener’) without affecting the correctness of event handling. This aligns with the LSP, ensuring that listeners are interchangeable. Also, this allows to store all event listeners in a single collection if needed.?
• Interface Segregation Principle (ISP): The segregation of interfaces (‘IAsyncEventListener’ and ‘IEventListener’) is a clear demonstration of adhering to the ISP. Clients (event listeners) are not forced to depend on methods they do not use, promoting a clean and efficient interface design.?
• Dependency Inversion Principle (DIP): The ‘EventDispatcher’ depends on abstractions (interfaces) rather than concrete implementations of event listeners. This adherence to the DIP ensures that high-level modules (the dispatcher) do not depend on low-level modules (listeners). Instead, both depend on abstractions, enhancing the component's flexibility and testability.?

Clean Code Excellence?

The "Events" component follows clean code principles. It employs clear and meaningful names for interfaces and classes, follows a consistent naming convention (IEvent, IEventListener, EventDispatcher), and maintains a logical structure. The code's readability and maintainability are further enhanced through the proper use of interfaces, showcasing a modular and organized design.?

1. Handlers (Query and Command Handlers)?

This component houses query and command handlers, which are crucial for processing user queries and executing commands in response to application requests. The UML diagram for Handlers provides an overview of the handler classes and their interactions.?

?

Domain-Driven Design (DDD) Harmony?

The "Handlers" component demonstrates a clear alignment with DDD principles by handling commands and queries, crucial elements of domain-driven applications. The use of the IHandler interface, which is implemented by ‘ICommandHandler’, ‘IAsyncCommandHandler’, ‘IQueryHandler’, and ‘IAsyncQueryHandler’, reflects the DDD principle of modeling domain-specific behavior.?

Additionally, the ‘HandlersResolver’ acts as an abstract factory to resolve handlers dynamically, aligning with DDD's emphasis on domain logic decoupled from infrastructure concerns. This enables the application to adapt to evolving business requirements effectively.?

SOLID Principles at Play?

Following is the breakdown of the SOLID Principles are used in the requests handling architecture.?

• Single Responsibility Principle (SRP): Each handler interface (‘ICommandHandler’, ‘IAsyncCommandHandler’, ‘IQueryHandler’, ‘IAsyncQueryHandler’) has a single responsibility, adhering to SRP. They focus on handling specific types of commands and queries, ensuring clarity and separation of concerns.?
• Open/Closed Principle (OCP): The architecture is open for extension. New handler implementations can be added (e.g., additional command or query handlers) without modifying existing code. This conforms to OCP, promoting maintainability.?

• Liskov Substitution Principle (LSP): While not explicitly mentioned, the component's design implies that handler implementations can be substituted for their base type (IHandler) without affecting the correctness of command and query processing. This aligns with LSP, ensuring handler interchangeability. Also, this allows to store all handlers in a single collection (non-generic – base handler) if needed.?
• Interface Segregation Principle (ISP): The segregation of handler interfaces (ICommandHandler, IAsyncCommandHandler, IQueryHandler, IAsyncQueryHandler) respects ISP. Clients (handlers) are not forced to depend on methods they do not use, promoting a clean and efficient interface design.?
• Dependency Inversion Principle (DIP): The ‘HandlersResolver’ depends on abstractions (interfaces) rather than concrete implementations of handlers. This adheres to DIP, ensuring that high-level modules (the resolver) do not depend on low-level modules (handlers). Instead, both depend on abstractions, enhancing the component's flexibility and testability.?

Clean Code Excellence?

The "Handlers" component adheres to clean code principles through clear and meaningful names for interfaces and classes, a consistent naming convention (IHandler, HandlersResolver), and a logical structure. The code's readability and maintainability are further enhanced through the proper use of interfaces, showcasing a modular and organized design.?

1. Specifications?

Specifications play a vital role in defining and enforcing business rules within the application. The “Specifications” component contains classes that represent business rules, ensuring data integrity and consistency. The UML diagram illustrates the structure of specification classes and their usage.?

?

Domain-Driven Design (DDD) Harmony?

The "Specifications" component aligns well with DDD principles, specifically in the context of enforcing business rules within the application. The ‘ISpecification’ interface, which represents specification implementations, is a DDD-inspired approach to encapsulating and enforcing domain-specific rules and conditions.?

Moreover, the ‘SpecificationsInvoker' acts as an abstract factory for invoking specifications, a crucial aspect of DDD where domain-specific logic is central to ensuring data integrity and consistency.?

SOLID Principles at Play?

Following is the breakdown of the SOLID Principles are used in the specifications pattern architecture.?

• Single Responsibility Principle (SRP): Each interface (ISpecification, IAsyncSpecification, and ISpecificationsInvoker) and class (SpecificationsInvoker) has a clear and single responsibility. The ‘ISpecification’ interface represents specifications, while the ‘SpecificationsInvoker’ is responsible for invoking them. This aligns with SRP, ensuring clarity and separation of concerns.?
• Open/Closed Principle (OCP): The architecture is open for extension without modifying existing code. New specification implementations can be added without changing the ‘SpecificationsInvoker, adhering to OCP's principles for maintainability.?
• Liskov Substitution Principle (LSP): The design implies that specification implementations can be substituted for their base type (non-generic ISpecification) without affecting correctness. This aligns with LSP, ensuring specification interchangeability. Also, this allows to store all specification in a single collection (non-generic – base ISpecification) if needed.?
• Interface Segregation Principle (ISP): The segregation of the generic interfaces (IAsyncSpecification and ISpecification) respects ISP. Clients (specification implementations) are not forced to depend on methods they do not use, promoting a clean and efficient interface design.??
• Dependency Inversion Principle (DIP): The ‘SpecificationsInvoker’ depends on abstractions (interfaces) rather than concrete implementations of specifications. This adheres to DIP, ensuring that high-level modules (the invoker) do not depend on low-level modules (specifications). Instead, both depend on abstractions, enhancing the component's flexibility and testability.?

Clean Code Excellence?

The "Specifications" component adheres to clean code principles with clear and meaningful names for interfaces and classes, a consistent naming convention (ISpecification, IAsyncSpecification, SpecificationsInvoker), and a logical structure. The code's readability and maintainability are further enhanced through the proper use of interfaces, showcasing a modular and organized design.?

?