One true domain model is an error?

I just finished work on a client who burned millions in a project to come up with a “one true domain model” for his business. This was the only goal of the project.

What do you think about this? Is the only version of the truth realistic?

+4
source share
4 answers

The key word here is "model." Any domain model is an abstraction of key entities and behavior in a system model.

As an example, a traffic control system may have a Car object that is indivisible. Driving simulations will have a much larger structure: components, weight, color, occupants, etc.

The fact is that there is no global definition of Car. There is only state and behavior that you care about your particular application (or even part of the application).

+4
source

No, this is unrealistic. Yes, this is a mistake ,-)

In my opinion, this is a well-known trade-off between reuse and maintainability. If there is one of the most important aspects of maintainability, I would say that it is: minimizing dependencies. The “One True Domain Model” for the entire business obviously creates a lot of dependencies, no matter how smart they are.

I would be better repaired.

+3
source

Hmm, domain model. Modeling is an abstraction method in which we create a representation of real objects that will abstract from (omit) unnecessary details (therefore, usually we need to specify important aspects in advance). A domain is a specific area of ​​business. The problem is that in the domain there can be different representations even in one organization and different points of view, therefore it is difficult to determine important aspects and, therefore, the model. The problem, which is even worse, is that this domain and these points of view change over time, and therefore the model can change over time - this is important when we talk about business agility. I personally think that domain models, especially when they should be used for a specific purpose, are too fluent. IMHO it is better to record the current state and view the domain / for the domain for a given task on demand.

+1
source

One thing that does not help is that you are not specifying a modeling language.

You probably mean a data model: relational, ER, UML classes, or something like that. Probably no. In any case, let's hope that the language used is clear enough to be at least a consensus on what information should be in the model and how it should be presented. Drawing boxes and lines with various types of shapes and decorations without a clear meaning will not give you good models.

Saying that my vote is for markus answer: the more information you include, the more you need to drag. In addition, what information you need and how to best model it depends on what you need this information for, how easily and reliably you can receive and store information, possibly in access control issues (can everyone see everything?) And besides other considerations, Without knowing these requirements and how they may change in the future, there is no such thing as a good model, much less an ideal one. Besides that, of course, there are internal considerations of quality - for example. redundant presentation of information is usually a bad idea unless you have a specific requirement that makes it attractive.

This does not mean that modeling or revising existing models is a waste of time: on the contrary, often you only realize the existing requirements or design limitations as soon as you try to design a model and consider its consequences. And it’s good to strive for a constant presentation, so that everything fits the possible single universal model of everything. But this, of course, is not the goal of modeling.

Perhaps it is necessary to think long and hard about what information they have, where it is needed, who supports it, how, and how it can all be improved. In this case, I believe that the goal of creating a unified, consistent and complete universal information model can be a good way to achieve it. But this model will probably not be the main result.

+1
source

Source: https://habr.com/ru/post/1305727/


All Articles