アナリシスパターンを理解する

最近立ち返ってDDD本を読み進めています。
今回は11章の気づきに関して取りまとめます。

概要

第11章ではアナリシスパターンについて解説している。
本記事ではそれに対する個人的な解釈を述べる。
実際にはアナリシスパターンは非常に抽象的な話で、概念的に理解するのはそこまで難しくはない。

アナリシスパターンとは

アナリシスパターンとは既存の業界についてすでに洗礼されたモデル（それはシステムとしてという文脈とは全く関係なくて構わない）が存在する際に、そのドメインを学習することでドメイン設計に対するアプローチとすることである。

本章では具体的に会計システムの開発を行う際に、会計の専門書を解読することで設計のアプローチとする例が取り上げられている。

また外部の知識と合わせて現場にドメインエキスパートがいるようであれば、ユビキタス言語を用いて設計をすり合わせることでより洗礼されたモデルを設計することができる。

これは非常に強力な手法であり、まず率先して取り入れるべき方法だと思う。
特にその業界に対する知見が全く無い場合丸腰で設計するのは自殺行為に等しい。
システムという側面に囚われすぎず、一般的な専門書などから得られる洞察は膨大なものになるだろう。

ドメインエキスパートについて

この例ではドメインエキスパートが出てき、開発者とともに簡素なクラス図のようなものを用いている。
だが実際に現場にいるドメインエキスパートがここまで開発側の用いている手法に対して理解があることは少ないのではないかと思う。
それは協力的な姿勢であったり、そもそも開発者が用いているクラス図がどのようなもので、どういったヒントを求めているかというコンテキスト的な解釈ができるかどうかという事も含めてである。

そういう意味で、本章に出てきているドメインエキスパートを含むチームはすでにチームビルディングに巧みに成功している例といえ、自分の経験上現実にこのような状況になることは難しい。

チーム全体がDDDを理解しているためには組織全体が積極的に働きかけ、エンジニアだけでなく広い範囲でこうした開発スキームの理解をし、さらに時間をかけて学習している必要がある。

否定的な意見を言ったが、現実的にはクラス図などを用いなくとも、ドメインエキスパートから話を聞くということだけでも大いに有益であり、これも積極的に取り入れることで恩恵に預かれる。

アナリシスパターンの肝

個人的に「業界知識」「ドメイン設計」「実装」この3つのバランスを上手く取ることがアナリシスパターンの肝だと感じる。
まず「業界知識」「ドメイン設計」の部分であるがこの2つは実際に最終的に落とし込む場合に異なる箇所が出てくる。当然全く同じ状態になるかとそうでもない。
アプリケーションを実現するということが第一目的であるため、独自の知識や組み合わせなどが出てくることがあるからである。
適切な境界やモデルが出来上がるまでに何度も設計を吟味してドメインを練り直す必要がある。この際に業界知識に引っ張られすぎてはいけない。

また「ドメイン設計」「実装」に関しては実装が持つルールやフレームワークを使用している場合、また言語の特性によってはドメイン設計をそのまま実装に落とし込むことが困難になる場合がある。
そのためドメイン設計を多少捻じ曲げて実装を行うこともある。
この際なぜそうなっているのかという証拠などを十分に残して置くことなどが大切になるのではないかと思う。