Should classes mimic reality or have optimal compatibility with the code?

Question

For the performance monitor, I implemented MVC in Java and decided to separate my model into separate classes, now I am torn between sorting its attributes and functions in Client , Server and Connection Model classes or Benchmark , Logging and Specs Model classes.

Former models will correspond to real life patterns as “objects,” since they are separate objects that the application will control. Thanks to the way MVC works with the observer, the reference function from my controller will trigger updates in all my models.

The latter will solve this widespread update, making the Models more functional (requirements), thus only updating the models that need to be updated, causing only the view-updates that need to be changed. I think this approach will reduce my reuse model.

Answer 1

Classes should concern reality, but not reach it. If you remained at an absolute abstract level, your model would not be able to achieve some kind of implementation. When you model your domain, you start with business objects that are directly related to (physical) objects in reality. After you start developing the system, you derive the class model from the business model, which is somehow connected. Usually you create dependencies on your system class design for the corresponding business objects, and you will also find naming concurrently. The relationship between the business model and the design model is loose (dependencies), but exists. Each business object must have some trace for the project model. There are likely to be more classes in the design model than in the business model.