関わっているあるプロジェクトで、Javaでのコンポーネントベース開発を進めるためのクラス図が出来上がりつつある。DDD（ドメイン駆動設計）に関心を持つ技術者にとってお手本になるような端正なドメインモデルだ。それを眺めながら関係者がしみじみと感じていることがある。どんなに優秀なドメインエキスパートと組んだとしても、DDDにもとづいてこのモデルを「先に」生み出すことは不可能だっただろう。 どういうことか。我々はまず、泥臭い分析と設計を重ね、あるべきデータモデルを完成させた。そのうえで実装方式の専門家の協力を仰ぎ、クラス図が出来上がった。つまり、データモデルからドメインモデルが導かれたのであって、その逆ではない。じっさい、ドメインモデルからデータモデルを導くことが不可能であったことは、両者を並べたら一目瞭然なのであった。 これは重要な論点だ。データモデリングとドメインモデリングのどちらを先行させ

マイクロサービス・アーキテクチャ(MSA)を適用する際に頭を悩ます問題のひとつが「複数サービスにわたる更新操作」である。マイクロサービスを成すソフトウエアのまとまりは、個々に独自のデータストアを持っている。ゆえに複数サービスを横断する更新操作の際、トランザクション管理によるACID特性を保証できなくなる。 この問題に対処するために二相コミットや結果整合性等の考え方があるが、どのやり方でも限界があるし、ある種の制約や余分な手間を受け入れざるを得ない。もっとも穏当な設計方針は「複数サービスに渡る更新が起こるような粒度ではサービスを切り出さない」である。個々のサービスを実装する段になって悩む前に、サービス粒度の設計に関して事前に考慮すべきことがあるということだ。 前回記事で説明した「CRUD基準によるサブシステム分割」は、更新制御の面から見たサービス粒度の設計基準として応用できる。ドメイン駆動設