21 lines
1.7 KiB
Markdown
21 lines
1.7 KiB
Markdown
# Development Rules & Guidelines
|
|
|
|
To ensure scalability, readability, and consistency across all microservices, the following architectural and coding rules must be adhered to:
|
|
|
|
## 1. Service Interfaces and Implementations
|
|
- **Single File Co-location**: Every service interface (e.g., `IAssetsDbService`) and its corresponding implementation class (e.g., `AssetsDbService`) **must** reside in the same file.
|
|
- **Naming Convention**: The file must be named after the implementation class (e.g., `AssetsDbService.cs`).
|
|
|
|
## 2. Mandatory Method Documentation
|
|
- **English Language**: All documentation must be written in English.
|
|
- **XML Documentation**: Every method (public, private, internal, or protected) must have proper XML documentation.
|
|
- **Required Fields**:
|
|
- `<summary>`: Clarifying the purpose and behavior of the method.
|
|
- `<param>`: Explaining each parameter (if applicable).
|
|
- `<returns>`: Specifying what the method returns (if applicable).
|
|
- **Implementation Inheritdoc**: For class methods implementing interfaces or overriding base methods, use `/// <inheritdoc />` to inherit documentation unless customization is needed. Note that any custom helper or private methods in the implementation must still have their own explicit XML comments.
|
|
|
|
## 3. Data Class & Model Architecture
|
|
- **Core Placement**: All data classes, DTOs, and shared enums (e.g., `AssetType`) that are or could be used by multiple services must be defined in the `FinlyticCore` project.
|
|
- **Service-Specific Exception**: Data classes and models may only reside in a specific service project (e.g., `FinlyticAssets`) if they strictly concern the internal operations of that service (e.g., raw API request/response structures for an integration that only that service manages).
|