マイクロサービスとドメイン駆動設計の設計思想のメモ

@yusuke_arclamp さん、@sugimoto_keiさんが、マイクロサービスとドメイン駆動設計の設計思想に語っているつぶやきが参考になったのでメモ。
以下は、疲れた頭で思いついたことを書き殴り。
間違っていたら後で直す。

【元ネタ】
マイクロサービスとドメイン駆動設計の設計思想のTwiiter拾い - Togetterまとめ

Martin Fowler氏がマイクロサービスの特徴について語る

マイクロサービス移行の代償

マイクロサービスとSOA

マイクロサービスアーキテクチャとは何か - arclamp

SOAとマイクロサービスを複合設計に当てはめると見えるもの: ソフトウェアさかば

マイクロサービスはコア資産 - Martin FowlerのMonolithFirstを読んで -: ソフトウェアさかば

さかばさんはTwitterを使っています: ".@akipii こんなのもあります。バズワードと考えると「うちはすでにこうやってる」というのがお決まりでしょうかね。/マイクロサービス，アプリケーション，システムを比較する http://t.co/pCTFSxO8r7"

【1】マイクロサービスとは結局、何なのか？

それは、@sugimoto_keiさんの下記のつぶやき「マイクロサービスの粒度は境界づけられたコンテキストと同程度」で、全ては言い尽くされていると思う。

杉本啓さんはTwitterを使っています: "マイクロサービスってのの元記事、初めて読んだ。サービスの粒度は、DDDで云うところの「境界づけられたコンテキスト」とだいたい同じ程度を想定してるんだね。「マイクロ」と呼ぶと、極端に小さな粒度を想定しているような誤解を与えないかね。http://t.co/VkJF8vQ7tV"

また、Webサービスの設計思想は、CORBA→SOA(例：SOAP)→マイクロサービス(例：REST)に至る歴史と同じ。
この辺りは、@yusuke_arclamp さんの記事「マイクロサービスアーキテクチャとは何か - arclamp」が詳しい。

今は、目的さえ合致すれば、オープンデータやマッシュアップのように、公開されたWebサービスのAPIを使ってすぐに手軽なWebシステムを作るのは簡単になっている。
その時の設計思想として、マイクロサービスという概念を用いることは有益だろう。

そして、マイクロサービスが過去のSOAと違って細かく使い勝手のいいAPIにしたい場合、ドメイン駆動設計の「境界づけられたコンテキスト」が使えるレベルにすればいいのだろう。
そうすれば、ドメインの枠内で一つのコンポーネントのように扱えるだろう。

【2】オブジェクト指向設計とデータモデリングの違いは何なのか？
一つの観点として、@yusuke_arclampさんのつぶやきが一つの解答になるのではないか。

鈴木雄介/Yusuke SUZUKIさんはTwitterを使っています: "そもそもオブジェクト指向は時間軸を表現するのは苦手。とはいえ時間軸をベースにする方式では集約がされずに再利用ができなくて効率が悪いという問題があります。だからモデリングによって時間軸における空間配置を検討し、適切なバランスを探すことが重要になります。"

たとえば、商品と倉庫というエンティティがあった場合、在庫はどんな概念として提示すべきか？という問題があったとする。
良くあるダメな例は、在庫エンティティを商品と在庫の連関エンティティで作ってしまう例だろう。
オブジェクト指向設計では、単純に、商品エンティティと倉庫エンティティの間に在庫エンティティを普通に作ってしまいがち。
在庫は、エンティティとして抽出すべきものではないと思う。

在庫は、商品の状態。
在庫から、どの時点の商品や倉庫に関連付けられるか、トレースできなければならない。

在庫は、倉庫の入出庫トランザクションから導出されるサマリテーブルとして作るべき。
つまり、在庫は、入出庫トランザクションから定期的にバッチで集計されるサマリテーブルであるべき。

オブジェクト指向設計は、「～マスタ」のようなリソース型エンティティを分析するのは強いと思う。
しかし、オブジェクト指向設計はトランザクションテーブルの分析は弱い気がする。

むしろ、データモデリングの方が、タイムスタンプを主キーに持たせることによって、トランザクションテーブルに時系列を強力に設置する仕掛けがあるような気がする。