ドメインについて(6)

ビジネスという関心事を分離し品質を向上させることがドメイン設計の目的である。

具体的にどのようにすればいいのか。云うまでもなくシステム開発ではアーキテクチャの選定が重要である。だがドメイン開発ではこのアーキテクチャは決まっている。これについては考える余地はない。レイヤーアーキテクチャである。レイヤーアーキテクチャではコア層であるドメインを中心に設計する。以下の文書が主な成果だ。
  1. ドメインクラス図:モデラーがビジネスエキスパートやクライアントからヒアリングしたビジネスの要素。
  2. ユースケース図:ドメインクラスとして分解したシステム要素をさらに機能(プロセス)に分解した成果。機能要件・非機能要件がこれにあたる。
  3. ロバスとネス分析図:ビジネスエキスパートやクライアントとのメモ的文書。ユースケース図とドメインクラス図の起点となる。正式な成果とはならない事も多い。
注目すべきはこれら文書の保守性の高さである。設計文書というのは下流になっても継続的に変更されるものである。だが一般的には設計書等の下流における変更コストは非常に高いという問題がある。だがドメイン化をすればその問題がなくなる。凝集度が高いためどこにどんな機能やデータがあるかが分かり易くなる。結果修正時間が短縮される。修正だけではない。内容を把握したり、検証する時間も短縮される。変更は影響範囲の調査が難しい。下流の開発者はビジネスに精通していない。変更をどのようにすればいいか分からない。それについては聞かなければならない。所がそのソースを見せてもAPIレベルのソースコードと一緒になっている。そのため調査に高いコミュニケーションコストがかかる。
だがドメインクラスが分離されていれば対応も容易となりコミュニケーションコストも安くなる。