エントリーの編集
![loading...](https://b.st-hatena.com/bdefb8944296a0957e54cebcfefc25c4dcff9f5f/images/v4/public/common/loading@2x.gif)
エントリーの編集は全ユーザーに共通の機能です。
必ずガイドラインを一読の上ご利用ください。
Thing と Thing-Type に知識を分離する : Knowledge Level パターン | システム設計日記
記事へのコメント0件
- 注目コメント
- 新着コメント
このエントリーにコメントしてみましょう。
注目コメント算出アルゴリズムの一部にLINEヤフー株式会社の「建設的コメント順位付けモデルAPI」を使用しています
![アプリのスクリーンショット](https://b.st-hatena.com/bdefb8944296a0957e54cebcfefc25c4dcff9f5f/images/v4/public/entry/app-screenshot.png)
- バナー広告なし
- ミュート機能あり
- ダークモード搭載
関連記事
Thing と Thing-Type に知識を分離する : Knowledge Level パターン | システム設計日記
エバンスは、Knowledge Level パターンを、ドメインモデルの構造設計、特に、ビジネスルールの変更に動... エバンスは、Knowledge Level パターンを、ドメインモデルの構造設計、特に、ビジネスルールの変更に動的に対応できるソフトウェアの構造という視点で、書いているらしい。 私は、どちらかというと、モデリングの基本テクニックとして、ドメインの概念・知識を、 ● Thing-Type クラス ● Thing クラス の2つに分離すると、うまく整理できることが多いよ、というモデリングの基本テクニックとしてとらえている。 性格の異なる知識を、別のオブジェクトに分離することで、片方の知識に変更があった時に、扱いやすくなる、というのは、もちろん大きなメリット。 でも、将来もあまり変化がないだろう知識でも、性格が異なる知識は、別のオブジェクトで管理したほう、ソフトウェアがわかりやすく、扱いやすくなる。 中古車 私が、Thing と Thing-Type に目覚めた(?)のは、中古車をネットで検索す