オンライントレードのサンプルシステムでDDDを学ぶという海外ブログ記事を読みながら、よちよち学習する話の続き。今回も参考情報をなぞっているだけなので、あまり役に立つ記事にはなっていない。
前回記事はこちら。
説明記事をまず丁寧に読んでみる
元ネタ記事では
という構成になっている。
とりあえず、記事を読んでみた。
システム構成の概略
システム構成はこんな感じ。
ユビキタス言語
ドメインモデル
エンティティや値オブジェクトに関する話。内容的には一般論である。最後に良いドメインモデルを作るためのヒントがいくつか紹介されていて興味深い。目についたものをピックアップ。
- 1図にあなたのドメイン全体を詰め込まない。オブジェクトとの関係の何百もの図は、正常な人間が理解できるものではない。ダイアグラムに書くオブジェクトは5〜9に制限する。
- 関係の交差は禁止する。関係を横断せずに、図を描くことができない場合、複雑すぎるということなので分割を検討する。
コンテキスト境界
複雑なドメインをどのように扱うのか（どう分解するのか）、についての話。これも内容的には一般論な気がする。
- 大きなドメインを小さく分割する魔法の公式はない。
- モデルは、外部の問題に気を取られたり混同されることなく、1チームで管理できるように十分に小さくする必要がある。
コマンドクエリ分離原則(CQS)
設計をシンプルに保ち、パフォーマンスを改善するための設計パターンであるCQSについての説明。
エリック・エヴァンスのドメイン駆動設計では「副作用のない関数（SIDE EFFECT FREE FUNCTIONS）」とあるもの(CQSはこの一種という理解)。ドメイン駆動とは直接的な関係は無くて、よい設計を行うためのパターンとして登場しているという理解。
手の込んだシステムへと組み立てることができて、それでも理解しやすい要素を作成するためには、モデル駆動設計に専念する際に、適度に厳密な設計スタイルが求められる。
エリック・エヴァンスのドメイン駆動設計
ソフトウェアをこのように設計するための公式はないが、私はここにパターンを一式集めてみた。経験上、これはうまく適合すれば、設計にしなやかさを与える傾向があるものだ。これらのパターンと例によって、しなやかな設計がどのようなもので、どういう考え方でそこに至るのかということについての感覚が得られるはずだ。
エリック・エヴァンスのドメイン駆動設計
階層化アーキテクチャ
特にOrder Management System（OMS）をクローズアップして、階層化アーキテクチャによりドメインと他のアプリケーションコードがどのように分離されているかを説明している。なおBullsfirstはUIとサービスを分離しているので、OMSはGUIは持たずREST serviceをインターフェイスとして持つ。コメント欄にも書かれているけど、一種のMicroserviceとも言えるという理解。
感想
というわけで元記事を読んでみたのだけれども、なにか洞察を得たかと言うとそうではない感じ。もちろん「良さそうな設計」という雰囲気はわかるのだけど、力不足でそれ以上の情報が読み取れない。
たとえばこんなところでモヤモヤしている。というわけで今度はコードを眺めながらいろいろ調べてみたい(挫折するかもしれないけれど)。
たぶん、つづく
