DOAとOOAの違い

@hatsanhatさんにDOAの質問をしたら、とても参考になる回答をもらったので、僕の理解の範囲内でまとめてみる。
＃間違いがあったら後で直す。

【参考】
モデラーとは:アーキテクト360

review 生産管理・原価管理システムのためのデータモデリング- Ynishi Bussiness Logs

Domain Logic and SQL - Ynishi Bussiness Logs

(1)リレーションシップはキーという「証拠」があるから引ける

OOAでは、クラス同士の関連は簡単に引ける。
クラス同士の関連はビジネス上の制約から発生するけれども、それを表現するのは多重度ぐらいしかない。
コンポジションと集約の違いはOOAではあいまいに表現されやすい。
実際、クラス図で関連がコンポジションなのか制約なのか、を意図的に明示するモデラーは少ない。
また、関連クラスは分析モデルで表現されるだけであり、実装モデルでは消えてしまう。

連関エンティティと関連クラス: プログラマの思索

しかし、DOAではエンティティ同士の関連はそう簡単に引けない。
リレーションシップを貼るには、親子・参照・派生関係のいずれかが必要であり、それらを真面目に考えると、キー(識別子)の整合性を考慮しないといけない。
キーをエンティティに作ると、キーによってエンティティの性質が固定化されてしまう。

@hatsanhatさんは、DOAは現実の業務（正確には帳簿組織）をどう設計するかを考えるが、ＯＯＡはオブジェクトという抽象的なものを仮定してそれの設計図を書こうとしているだけに過ぎない、と言われているが、なるほどと思う。
OOAは、既に要件が固まって概念モデルが固まった後の設計工程では、開発までスムーズに連携できるが、肝心のシステムの全体像を見出す工程は正直難しい。
アナリシスパターンやドメイン駆動設計は、システム化提案や要件定義などで出てくる概念モデル設計で役立つアイデアだが、DOAのような厳しい制約を課すわけではないので、経験値が高くないとOOAは難しいだろうと思う。

(2)DOAでは、親子・参照・派生関係の3つの制約の違いを理解しておくのが重要

親子関係は、注文ヘッダ・注文明細のように主キーが複合キーになる。
普通は、二つのマスタの値の組み合わせとして、連関エンティティとして生成される時が多い。

参照関係は、注文ヘッダと顧客マスタのように、外部キーという参照制約がある。
普通は、二つのエンティティに業務の制約条件が発生する場合、外部キーというリレーションシップが自然に現れる。

UMLなら、親子関係はコンポジション、参照関係は集約として表現できるだろう。
だが、ER図を書く時に、二つのエンティティの関係を、親子関係と参照関係で使い分けるのは結構難しい。
全てを外部キーとして表現できるし、逆に連関エンティティを作りまくることもできる。

二つのエンティティ(リソース・イベント)のリレーションシップの張り方については、T字形ERが鮮やかに解決している事は下記で書いた。

候補キーと2次識別子に関する概念: プログラマの思索

自分流モデリング探しの旅(2)～T字形ER データベース設計技法 - papandaDiary - Be just and fear not.

もう一つの関係である派生関係は、UMLなら単なる継承に過ぎないが、DOAで派生関係が出てくるモデルを読みとくのはかなり難しい。

DOAの派生関係がOOAの単なる継承と違うのは、排他と共存の2種類があるからだ。
過去の記事でも書いた。

データベース設計で派生関係は難しい: プログラマの思索

派生関係の場合、スーパータイプ(親)とサブタイプ(子)の主キーは必ず一致する。
排他の派生関係は、UMLと同じ普通の「完全」な継承であり、スーパータイプはサブタイプの真部分集合になる。
サブタイプ同士のデータは相容れない。
普通は、スーパータイプに「～区分」「～種別」というフラグでサブタイプの関係を明示する。

共存の派生関係は、NULL値排除のためにサブタイプを作る。
例えば、取引先マスタに得意先や仕入先の情報を区別したい場合は、取引先マスタをスーパータイプ、得意先マスタや仕入先マスタはサブタイプにする。
この場合、得意先でもあり仕入先でもある取引先は、3つのマスタに存在するため、排他ではなく、共存になる。
UMLでは、共存の派生関係は、クラス同士のロールで表現できる。

下記にある「データモデル表記読み替えハンドブック」を参考にするとよい。

データモデル表記読み替えハンドブック: プログラマの思索

@hatsanhatさんから、DOAの派生関係が難しい理由は、OOAでは要素から上に向かってグルーピングするしていくので簡単だが、DOAでは逆に集合から真部分集合を切り出す作業であり、しかも切り出すためのデータ項目(区分値)やキーがないとスーパータイプを作れない、と教わって、ようやく理解できた。

又、@hatsanhatさんから、T字形ERがNULL値排除にこだわる理由は「index-only」という実装方法にある、と教わって、ようやくNULL値排除の本当の理由が分かったような気がした。
NULL値排除のために共存の派生関係を作っているので、全てのカラムにインデックスを貼ることができ、検索を高速化することも可能なのだろう。
共存の派生関係が出てくるとスーパータイプとサブタイプをJOINしなければ、本来のデータを取得できないため、SQLも複雑になってくるからだ。

DOAの派生関係は、特に生産管理システムや在庫管理システムで頻繁に出てくる。
部品(品目)、受払(入出庫)、ロケーション(在庫、倉庫)の派生関係を理解して、それらのサブタイプを区別していくのは、業務知識だけでなくモデリングの技法も分かっていないとそう簡単にモデリングできないだろう。

(3)渡辺幸三さんの本が他のDOA本よりも優れている点は、下記の説明があることだと思う。

(3-1)ボイスコッド正規化は2次識別子の制約を課す
(3-2)継承属性を明示することで暗黙的なリレーションシップを見出す
(3-3)「アナリシスパターン―再利用可能なオブジェクトモデル (Object Technology Series)」「エリック・エヴァンスのドメイン駆動設計」のように、モデルを色んな観点で分析して揺さぶり、洗練させていく
(平鍋さんは渡辺幸三さんの本を、日本人が書いたアナパタと絶賛していた)

モデリングとプログラミングの観点の違い: プログラマの思索

児玉公信さんの「UMLモデリングの本質」、佐藤正美さんのT字形ER、真野正さんの「実践的データモデリング入門」を読んで、やっとDOAを少しずつ理解できてきたように思う。
個人的には、渡辺幸三さんには、「アナリシスパターン―再利用可能なオブジェクトモデル (Object Technology Series)」「エリック・エヴァンスのドメイン駆動設計」のように、DOAパターン集のような本を出して欲しいと思う。