Separate static miner configuration information from real-time state information #55
Description
Currently, the miner's data model groups together both static configuration information (e.g., name, hash_rate_max, power_consumption_max, etc.), which remains unchanged over time after its configuration, and real-time data information (e.g., hash_rate, power_consumption, status, etc.), which instead varies over time.
In adherence to the single responsibility principle (see SOLID principles), and as has already been done for the other domain elements (e.g., energy source), the best choice is to separate the two concepts into distinct data models.
We could create a modeling that makes the two domain concepts more explicit by creating two different data models in this way:
Miner: As the principal entity, representing the physical asset and its intrinsic properties (maximum hash rate, maximum power, etc.).MinerStatus: Represents a snapshot of the miner's operational state at a given moment. This could be modeled as a Value Object, depending on the requirements.
The separation between configuration data and state data (real-time) provides a threefold architectural advantage. First, it improves performance, ensuring that high-frequency write operations on state data neither block nor "dirty" the configuration table, which is frequently read but rarely modified. Second, it allows for the independent scalability of services or databases: it's possible to upgrade the resources managing real-time data without affecting those dedicated to configuration (or simply, it's possible to use different storage technologies thanks to the implementation of the repository pattern). Finally, it increases code and model clarity, making the intent and function of each component immediately recognizable.