Innovative.CleanArchitectureTemplates 1.0.1

Template Features: 

1. Interfaces of Repositories in Domain Layer: In this template, the interfaces of repositories are defined and stored in the Domain Layer. The Domain Layer represents the core business logic and contains the domain models and business rules. By placing the repository interfaces in the Domain Layer, we enforce the principle of separation of concerns, ensuring that the domain remains independent of the data access implementation details in the Infrastructure Layer.<br/><br/>
2. Prepared ValueObjects: To combat Primitive Obsessions and promote a rich domain model, this template includes the use of Value Objects. Value Objects are small, immutable objects that encapsulate a specific domain concept. They are designed to be used as whole values, and their equality is determined by their attribute values. By including prepared ValueObjects in the template, we encourage developers to create dedicated domain-specific abstractions, leading to a more expressive and type-safe codebase.<br/><br/>
3. Entities and Aggregate Roots: In this template, we distinguish between Entities and Aggregate Roots, both of which are essential concepts in Domain-Driven Design. Entities: Entities represent domain objects with a unique identity and a mutable state. They encapsulate business logic and behavior and are integral to the core domain model. In the context of the template, entities are defined within the Domain Layer. Examples of entities in an e-commerce application could be "Customer," "Product," or "Order." Each entity has a globally unique identifier (ID) that distinguishes it from other entities if this is setup in the object. Aggregate Roots: Aggregate Roots are special types of entities that act as the entry points to the aggregate - a cluster of associated entities that are treated as a single unit. Aggregate Roots ensure consistency and transactional boundaries within the aggregate. The template recognizes the significance of Aggregate Roots and designates them as the primary points of access to interact with the Domain Layer. In the e-commerce application example, the "Order" entity could be the Aggregate Root, encapsulating "OrderItem" entities within it. <br/><br/>By distinguishing between Entities and Aggregate Roots, the template encourages developers to design domain models that maintain a clear and consistent representation of business concepts while enforcing encapsulation and transactional consistency within aggregates. This promotes a cleaner and more maintainable domain model in line with Domain-Driven Design principles.<br/><br/>
4. Dependency Injection Splitting between Application and Infrastructure: In this template, the Dependency Injection (DI) is split between the Application Layer and the Infrastructure Layer. The Application Layer is responsible for orchestrating the interactions between the Domain Layer and the Infrastructure Layer. It contains application services that utilize the interfaces of repositories defined in the Domain Layer to perform domain-specific operations. These services are registered in the DI container.<br/><br/> On the other hand, the Infrastructure Layer is responsible for implementing the interfaces defined in the Domain Layer, such as repositories and other technical concerns like data access. These implementations are registered in the DI container separately. This separation ensures a clear boundary between the application's core logic and technical details, promoting better maintainability and testability.<br/><br/>
5. IRepository Structure: The template follows the common IRepository structure, where each domain entity has its own repository interface. For instance, if we have a domain entity "Product," the IRepository structure would typically include an interface named "IProductRepository" in the Domain Layer. This interface declares methods for basic CRUD operations related to the "Product" entity. By adhering to this IRepository structure, the code remains organized, and it's easier to manage different domain entities' data access operations. The IRepository structure facilitates the decoupling of the Domain Layer from the data access implementation, making it possible to switch out different database technologies without affecting the core business logic. <br/><br/>
6. Central Package Version Management (Directory.Packages.Props): In larger projects, managing package versions across multiple projects can become challenging. To address this, we utilize a Directory.Packages.Props file that centralizes the management of package versions. This file lists all the required packages and their corresponding versions in one location, allowing developers to easily update or modify package versions across the entire solution. Centralized package version management ensures that all projects within the solution use the same package versions, reducing the risk of version conflicts and ensuring consistent behavior throughout the application. <br/><br/>
7. Central Property Management (Directory.Build.Props): Similar to central package version management, we employ a Directory.Build.Props file to centralize property management for the solution. This file includes common build properties that are shared across projects, such as compiler options, build configurations, or paths to external tools. Centralized property management ensures that the same build settings and configurations are applied consistently across all projects within the solution. This simplifies maintenance and promotes standardization, making it easier for developers to understand and navigate the project's build process. <br/><br/>By incorporating central package version management and property management, our evolving template promotes consistency and maintainability across the entire solution. These practices make it easier for developers to manage dependencies and build configurations, allowing them to focus more on writing business logic and less on dealing with configuration-related issues. As the solution grows and more templates are introduced, these practices will facilitate smoother integration and collaboration among the different parts of the application.