On the subject domain modeling in terms of OOP

This wonderful article pushed me to publish long-standing thoughts on subject domain modeling using object-oriented programming.

To the relevance of the ideas outlined in the article, you come implicitly (without being able to express it because the modeling paradigm in terms of set theory is not taught in universities, future “programmers”, at least), while working with OOP and relational databases:

Every time when modeling the domain, using OOP terms (we are not talking about the business analysis stage, but about the subsequent stage of the model implementation in the code), for all entities of the subject domain, the following pattern consisting of their “sub-entities” has to be implemented in the database code and schema related to each other:

• class / table of the type “Machines” (hereinafter, the class is used in terms of OOP);
• class / table of the “List of machines” type;
• class / table type "Machine".

Next, using the OOP mechanisms and the relational model, the “sub-entities” are interconnected.

Moreover, the terms “essence” and “sub-essence” apply specifically to the domain model in terms of set theory,
and in terms of OOP / relational model, the terms “meta-essence” and “essence” are relevant, respectively.
I hope you understand why? - OOP / relational model are lower-level mechanisms, and the essence of the subject area has to be designed, there are no means in them that would in a native way reflect the essence of the subject area.
')

And then the expected problems follow:

Every time (not only in each project, but inside the project for each entity, let me emphasize this) do we implement a pattern?
Great, we do copy-paste.

[offtopic] Looking aside, I would like to say that I am rather critical of patterns (the theme is so fashionable 10-15 years old already; what, after all, they don’t think up instead of being engaged in modeling and writing high-quality code),
because the pattern is copy-paste in essence (if someone wants to argue on the topic - please, not here, get a publication, we'll talk there). [/ offtopic]

Or, if you want to reduce your work / do not engage in copy-paste (or in the absence of an understanding of the need to implement the described pattern), in most cases only one entity is implemented:

1. Code:
   
   • “Machine” class is not a set, but the characteristics of the machine, its description;
   • the list of machines is presented as an array (Array), a list (List), or an enumeration (IEnumerable), i.e. low-level data types of the language are used to implement the “list” entity - but with such data we can do everything we want or happen by chance, and this is no longer an object, but a procedural approach with all the consequences;
   • the class "Machines" is often not implemented at all in any way.
2. DB:
   
   • As a rule, this is one table “Machine” or “Machines” - a table, the rows of which contain a list of machines, and the columns - the characteristics of machines.
   • We wondered why in the books on the database such a table is called “Machine”, then “Machine” (Student / Student s )? And there are frameworks for working with the database, which are forced to the names of the tables add the suffix " s " (Mashine s / Student s ).
     The reason is that here an attempt is made to merge two entities into one (an object and a list of objects), or even all three into one.
   • It is correct to call such a table “Machine”, and “List of Machines” and “Machines” to implement using other tables.

So, what conclusion I draw on the basis of my experience and commented article:

I would like to have such a programming language, a development platform, a database theory, a DBMS that would allow in the “native” terms to implement the domain model in terms of set theory.
I think the need for the emergence of such tools in the mainstream has long been overdue.