思考と現場の間で

「いいサービスづくり」のために、組織づくりやソフトウェア設計など、考えていることを書きます

【DDDメモ】抽象化されたコア

抽象化されたコア

エリック・エヴァンスドメイン駆動設計 P.441

 別々のモジュールに置かれたサブドメインの間で大量の相互作用があると、モジュール間で多数の参照を生成する必要が生じて、分割したことの価値をほとんどなくしてしまうか、相互作用を間接的に行わなければならなくなって、モデルがあいまいになるかのいずれかとなる。
 分割する線を垂直にではなく、水平に引くことを検討すること。多態性によって、抽象型のインスタンス間にある詳細なバリエーションの多くを無視出来るようになる。モジュール間の相互作用のほとんどが、叩いてきなインターフェースのレベルで表現出来れば、それらの方をリファクタリングして、特別なコアモジュールに入れるのは意味のあることかもしれない。


~中略~


モデルにおける最も根本的な概念を識別し、それを別のクラス、抽象クラスまたはインターフェースにくくり出すこと。この抽象的なモデルは、重要なコンポーネント間の相互作用をほとんど表現するように設計すること。この抽象的なモデル全体を独自のモジュールに入れること。ただし、特殊で詳細な実装クラスは、サブとメインによって定義されたモジュールに残すこと。

作ることを考え始めると、そのシステムの目的を見失いやすくなる。もちろん作る際は、詳細やレアケースも含めて考える必要あるが、価値や目的の視点で見ると、それほど重要ではないことのほうが多い。そういう意味で、意識的だけではなく、モデルとしてコアドメインとそれ以外をいかに明確にしておくかというのが大切になってくるのではないか。

リファクタリング対象を選ぶ

エリック・エヴァンスドメイン駆動設計 P.443

うまく分解されていない巨大なシステムに遭遇したら、どこから手をつければよいだろう?XPコミュニティにおいて、その答えは以下のどちらかになる傾向がある。

  1. すべてリファクタリングが必要なのだから、どこから着手しても構わない。
  2. どこであれ困っているところから始める。自分の作業をかたづけるのに必要なものをリファクタリングする

 だが、私はどちらも支持しない。前者は、トッププログラマだけで構成されたごく僅かなプロジェクトを覗いて、現実的ではない。後者は、重箱の隅をつつくことになりやすく、対処療法はしても根本原因を無視し、最もひどくもつれた場所を敬遠してしまう。結局、コードはどんどんリファクタリングしにくくなる。


 では、すべてには手が回らず、かといって困ったときだけ対応することもできない場合、どうすれば良いだろうか?

  1. 困ったときのリファクタリングをする際に、原因がコアドメインかコアと補助的要素の関係を含むものかどうかを調べる。そうであれば、歯を食いしばって、まずそれを修正すること。
  2. 自由にリファクタリングする余裕がある場合、最初に集中すべきなのは、コアドメインのより適切なくくり出し、コアの隔離の改善、補助的なサブドメインから不純物を取り除くことによる汎用サブドメイン化である。

 これがリファクタリングという出費によって、最大の効果を上げる方法なのだ。

対象が大きくても、コアドメインを如何にくくりだしていくかを考えていくというのは納得。自分としても、まずは影響の少ないところから、という風にやってしまうが、それは少し目的が違うかもしれない。こういう方向で考えていこう。