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

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.

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