この素晴らしい記事は 、オブジェクト指向プログラミングを使用したドメインモデリングに関する長年の考えを発表するきっかけとなりました。
あなたは記事で提示されたアイデアの関連性に達します（集合理論の観点からのモデリングパラダイムは少なくとも大学、将来の「プログラマー」で教えられていないため、表現できません）、OOPとリレーショナルデータベースで長い間働いています：
ドメインをモデル化するたびに、OOPの観点から（ビジネス分析の段階ではなく、コードでモデルを実装する次の段階について）、ドメインのすべてのエンティティについて、コードとデータベーススキームで次のパターンを実装する必要があります。関連：
- 「マシン」タイプのクラス/テーブル（以降、OOPの観点からクラスを使用します）。
- 「マシンのリスト」タイプのクラス/テーブル。
- クラス/テーブルタイプ「マシン」。
次に、OOPのメカニズムとリレーショナルモデルを使用して、「サブエンティティ」がリンクされます。
さらに、「エッセンス」および「サブエッセンス」という用語は、集合論の観点から対象分野のモデルに正確に適用できます。
また、OOP /リレーショナルモデルの観点では、「メタ物質」および「本質」という用語が適切です。
理由がはっきりしているといいのですが？ -OOP /リレーショナルモデルは下位レベルのメカニズムであり、サブジェクトエリアのエッセンスを構築する必要があります;サブジェクトエリアのエッセンスをネイティブに反映するツールはありません。
そして、予想される問題は次のとおりです。
毎回（各プロジェクトだけでなく、各エンティティのプロジェクト内で、これを強調しています）パターンを実装しますか？
コピーペーストを行います。
[offtopic]気が散っているので、私はパターンに非常に批判的だと言いたいです（このトピックは既に10〜15年流行しています。高品質のコードを作成して書くのではなく、考えてみてください）。
なぜなら パターンは本質的にコピー＆ペーストです（誰かがトピックについて議論したい場合-ここではなく、出版を始めてください、そこで話をします）。
または、作業を減らしたい/コピーペーストを行わない（または、説明したパターンを実装する必要性を理解していない）場合、ほとんどの場合、これは1つのエンティティのみが実装されます。
- コード：
- クラス「マシン」-多くではない、すなわち、マシンの特性、その説明;
- マシンのリストはとにかく表されます-配列（Array）、リスト（List）、または列挙（IEnumerable）、つまり 言語の低レベルのデータ型は、「リスト」の本質を実装するために使用されます-しかし、そのようなデータを使用すると、私たちが望むものや偶然に起こることを何でも行うことができます。
- 「機械」のクラスは、ほとんどの場合、どのような形でもまったく実現されません。
- DB：
- 原則として、これは「Machine」または「Machines」という1つのテーブルです。テーブルには、行にマシンのリストが含まれ、列にはマシンの特性が含まれます。
- データベース上の本で、このようなテーブルが「Machine」または「Machine」（Student / Student s ）と呼ばれる理由を疑問に思ったことはありませんか？ また、テーブル名にサフィックス " s "（Mashine s / Student s ）を強制するデータベースフレームワークがあります。
その理由は、2つのエンティティを1つ（オブジェクトとオブジェクトのリスト）に結合しようとしたり、3つすべてを1つに結合しようとしたりするためです。 - このようなテーブルを「マシン」、「マシンのリスト」および「車」と呼んで、他のテーブルを使用して実装するのは正しいことです。
それで、私の経験とコメントされた記事に基づいて、どのような結論を導き出しますか：
集合論自体の観点から「集合」論の観点からドメインモデルを実装できるようなプログラミング言語、開発プラットフォーム、DB理論、DBMSが必要です。
このようなツールがメインストリームに登場する必要性は、長らく待ち望まれているように思えます。