On the subject of domain modeling in terms of OOP

    This wonderful article prompted me to publish long-standing thoughts regarding domain modeling using object-oriented programming.

    You come to the relevance of the ideas presented in this article (not being able to express it because the modeling paradigm in terms of set theory is not taught at universities, future "programmers", at least), working for a long time with OOP and relational databases:

    Each when modeling a domain, in terms of OOP (now we are not talking about the stage of business analysis, but about the next stage of implementing the model in the code), for all entities of the domain, we have to implement the following pattern in the code and database scheme: nd their "subentity" interconnected:
    • class / table of the type “Machines” (hereinafter I use the class in terms of OOP);
    • class / table of the type “List of machines”;
    • class / table type "Machine".

    Further, using the mechanisms of OOP and the relational model, “sub-entities” are linked together.

    Moreover, the terms “essence” and “subsubstance” are applicable specifically to the domain model in terms of set theory,
    and in terms of OOP / relational model, the terms “metasubstance” and “essence” are relevant.
    I hope it’s clear why? - OOP / relational model are lower-level mechanisms, and the essence of the subject area has to be constructed, they do not have tools that would natively 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, I emphasize this) we implement the pattern?
    Great, we do copy paste.

    [offtopic] Being distracted, I would like to say that I am quite critical of patterns (the topic is so fashionable for 10-15 years already; why don't they come up with it instead of modeling and writing high-quality code),
    because a pattern is copy-paste in its essence (if someone wants to argue on a topic - please not here, start a publication, we'll talk there). [/ offtopic]

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

    1. The code:
      • class "Machine" - not a lot, namely the characteristics of the machine, its description;
      • the list of machines is represented anyhow 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 essence of the “list” - but with such data we can do whatever we want or what happens by chance, and this is not an object but a procedural approach with all the consequences;
      • the class of “Machine” is most often not realized at all in any form.
    2. DB:
      • Typically, this is a single “Machine” or “Machine” table — a table whose rows contain a list of machines and the columns are the characteristics of machines.
      • Have you ever wondered why in books on the database such a table is called either “Machine” or “Machine” (Student / Student s )? And there are database frameworks that force the suffix " s " (Mashine s / Student s ) to the table names .
        The reason is that here an attempt is made to combine 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 “Cars” to implement using other tables.

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

    We would like to have such a programming language, development platform, DB theory, DBMS that would allow us to implement the domain model in terms of “native” terms in terms of the theory of sets.
    It seems to me that the need for such tools to appear in the mainstream is long overdue.

    Also popular now: