Home
Welcome to the wiki page for SoonMonoCleanStore. This document aims to serves as a comprehensive guide to the project, covering various aspects including setup, usage, architecture, and contribution guidelines. The content will be updated from time to time.
Follow these steps to set up and run SoonMonoCleanStore on your local machine:
-
Clone the Repository:
git clone https://github.com/yourusername/SoonMonoCleanStore.git cd SoonMonoCleanStore
Before running the SoonMonoCleanStore application, you need to set the database. Follow these steps: 0. Make sure mysql is installed
-
Run all db script provided at folder MySql in MySql which can be found at ~\SoonMonoCleanStore\Persistance\DatabaseScript\MySQL.
-
Update the
ConnectionStringssection with your database connection information. -
Open the
appsettings.jsonfile in the 'SoonMonoCleanStore' project. -
Update the
ConnectionStringssection with your database connection information.
Vertical slices are the fundamental organizational concept of SoonMonoCleanStore. Each vertical slice represents a specific feature or module of the application. This approach offers several advantages:
-
Modularity: Each slice encapsulates all necessary layers (Domain, Application, Infrastructure, and UI) related to a feature, making it easy to manage and extend.
-
Independence: Slices are independent of each other, reducing dependencies between features and allowing for isolated development and testing.
-
Flexibility: While most slices follow the Clean Architecture principles, vertical slices provide flexibility. Not all slices need to implement Clean Architecture; some can have their own design based on the scenario, allowing for adaptation to specific requirements.
-
Clarity: The architecture 'screams' the intent of the application, with each slice representing a clear and distinct functionality.
The Presentation Layer in SoonMonoCleanStore is responsible for handling user interfaces and interactions. It's the outermost layer and is designed to present data to users and receive user inputs. While the core of the application's business logic resides in the lower layers, the Presentation Layer ensures a user-friendly experience.
Key responsibilities of the Presentation Layer include:
- Handling HTTP requests and responses: The API controllers in the 'SoonMonoCleanStore.API' project serve as the entry points for external clients, handling HTTP requests and returning appropriate responses.
- API Documentation: Generating and maintaining documentation for API endpoints, often using tools like Swagger, to make the API accessible to developers.
The Presentation Layer is essential for creating a user-friendly and secure interface to interact with the core features provided by the vertical slices. It acts as a bridge between the user or external systems and the underlying application logic.
Within each vertical slice, SoonMonoCleanStore adheres to the principles of Clean Architecture, providing a clear separation of concerns and responsibilities across layers. For example:
The Domain Layer in each slice encapsulates the core business logic and rules specific to that feature. For instance, the Customer entity in the 'Customer' slice.
-
Entities: Domain entities, such as
Customer, hold the business state and behavior, embodying the core business rules.
The Application Layer within a slice houses specific business use cases and their corresponding handlers. For example, the 'Customer' slice has CustomerSlices.UseCases.
-
Use Cases: Each feature defines its use cases and handlers, implementing business logic unique to that slice.
-
MediatR and CQRS: SoonMonoCleanStore utilizes MediatR for command and query handling, ensuring a clean separation of responsibilities.
-
CQRS (Command Query Responsibility Segregation): CQRS is a design pattern used to separate the operations that read data (queries) from the operations that update data (commands). In SoonMonoCleanStore, CQRS is employed to enhance the separation of concerns between reading and writing operations. This separation allows for optimizing the read and write sides independently, leading to improved performance and scalability.
The Repository Layer in a vertical slice manages the creation of database queries needed to be sent over to the database via the DapperPersistence layer. The reason why we separate the database query execution from the database query building is because we want to have the flexibility of switching database access technology easily. One might prefer ADO.NET, EF Core, or SQLSugar framework. By separating it like this, the concern of how we communicate with the database is taken care of in another layer, which will be easy to change.
-
Repositories: Repositories, such as
CustomerSlices.Repository, handle data access and mapping between domain and database models. -
Dependency Injection: The Infrastructure Layer employs .NET 6 Dependency Injection container to provide essential services to other layers.
Certain components are shared by all vertical slices, promoting code reuse and consistency:
-
Infrastructure: The 'Infrastructure' project provides a set of common functionalities, services, and configurations used across all slices.
-
DapperPersistence: The 'DapperPersistence' project handles database query building, CRUD operations, and database queries using Dapper and SqlKata. It's shared among all slices for database interactions.
-
SharedKernel: The 'SharedKernel' project contains shared code, domain objects, utility functions, and module service interfaces that are common across multiple slices.
To facilitate inter-slice communication and shared functionalities, SoonMonoCleanStore introduces module services. These services allow one slice to interact with another slice's functionality through well-defined interfaces. Here is an example of a module service:
The 'ProductCommandService' is responsible for providing product-related commands and functionalities to other slices. It implements the 'IProductCommandServices' interface defined in the 'SharedKernel' project. Here are some of its key responsibilities:
-
GetProductStockCount: Retrieves the stock count of a product by its ID.
-
UpdateProductStockCount: Updates the stock count of multiple products based on a dictionary of product IDs and purchased quantities. It utilizes the 'DapperPersistence' project to execute a stored procedure for bulk updates.
This module service enables slices that require product-related operations to interact seamlessly with the 'Product' slice's functionality.
To add a new module or feature to SoonMonoCleanStore, follow these steps:
-
Create a New Vertical Slice: Start by creating a new vertical slice for the feature. Each slice should have its own set of Domain, Application, Infrastructure, and UI layers.
-
Implement Clean Architecture (Optional): Within the new slice, adhere to Clean Architecture principles, separating concerns across layers as described above.
-
Integrate with Shared Kernel: Utilize the 'SharedKernel' project for shared code and functionalities that are common across multiple slices.
-
Configure Dependency Injection: In the Infrastructure Layer, configure dependency injection to provide services to other layers within the slice.
-
Extend 'DapperPersistence': If necessary, extend the DapperPersistence project to include data access specific to the new feature.
By following these steps, you can seamlessly integrate new modules into SoonMonoCleanStore while maintaining architectural consistency and modularity.
SoonMonoCleanStore's architectural design, driven by vertical slices and Clean Architecture principles, offers a scalable, maintainable, and intuitively organized backend API. The 'Screaming Architecture' ensures that the purpose and functionality of the application are immediately apparent, making it easy to manage and expand.
If you wish to contribute to SoonMonoCleanStore, please follow these guidelines:
-
Bug Reports and Feature Requests: Use the issue tracker to report bugs or request new features.
-
Pull Requests: Submit pull requests with clear descriptions and details of the changes made.