# 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).