デッドライン読書会第54回の課題図書は前回に引き続き「要件最適アーキテクチャ戦略」の後半になります。今回の範囲は7章からになります。
目次をながめてみる
後半の目次はこんなところ。
Part 2 イノベーションを促進する
（途中から）
第7章 ドメインの概念をモデル化する
Part 3 イベントファーストアーキテクチャ
第8章 基礎的なアーキテクチャ
第9章 メッセージ駆動型アーキテクチャとイベント駆動型アーキテクチャ
Part 4 目的を持ったアーキテクチャの2つの道
第10章 モノリスを目的どおりに構築する
第11章 モノリスからマイクロサービスへの悠然たる移行
第12章 必要なバランスとデマンド戦略
イベント駆動型アーキテクチャを中心に技術的な話があるのがPart3。アーキテクチャの知識を持った上でのビジネス戦略を議論するのがPart4です。Part4の冒頭で著者が言及していましたが、本書の後半も技術的な内容というより、ビジネス戦略を検討する上で経営者（？）が知っておくべき選択肢について議論しているような流れでした。
気になった点をピックアップ
オーケストレーションとコレオグラフィー
コレオグラフィーっていう言葉は本書で初めて知りました。モノリスからマイクロサービスへアーキテクチャ転換する際に、各サービスをどのように統制を取るかというパターン（アーキテクチャの方針）。オーケストレーションは指揮者のように各サービスを統制する仕組みがある方式（オーケストラと同じ）。コレオグラフィーはそれぞれのサービスが独立して（各サービスとしての）責務をこなして連携する方式。この2つの区分の仕方はどうもかなり昔からあったんですね。SOAの時から？ひょっとしたらもっと前からかも？
ちなみに定義をネットで探していたら、Google Cloudでのオーケストレーションとコレオグラフィーの解説記事を発見しました。本書における議論の、Google Cloudでの実装という具体例になりそうです。
トランスフォーメーションの口実
トランスフォーメーション（DX）を実現するために、マイロサービスやクラウドネイティブのシステムを追求するわけではなく、戦略的なビジネス目標の達成に向けた実験を行うことが重要。下記は引用です。
マイクロサービスやクラウドネイティブのシステムを追求する口実として「トランスフォーメーション」を使うことは、イノベーティブでもなければ、差別化を図るものでもない。この活動方針に従うことが利益につながらなければならない。
P.292 12.2.8 バランスは公平に、イノベーションは絶対に
モノリスかマイクロサービスか
本書を読むに当たって一番気になるのが、モノリスかマイクロサービスかの整理ですかね。ビジネス戦略に沿って考え出されたモジュール化されたモノリスとマイクロサービスではどちらのほうが優れているかなどはなさそう。Pro-Conを比較し、提供するビジネスに適したアーキテクチャを選択するようにと。
これらの前提として大きな泥だんごアーキテクチャ（BBoM）から抜け出すようにするのが第一歩であるとし、ステップバイステップでアーキテクチャを改善していく道を11章と12章で示していました。ちなみに大きな泥だんごはこれ。
私が開発にたずさわるようなシステムはモジュール化されたモノリスを確実に作れるようになることが大事そうだと感じましたね。本書で提示されているモノリスに対する課題と目標は次のとおりでした。
１ モノリスを最初から正しく作成、その状態を維持する。
２ 正しく作成されていないモノリスを正しい状態にする。
３ モノリスからマイクロサービスに移行する。
第10章 モノリスを目的通りに構築する
次は？
最近出版された「人が増えても速くならない」とかどうですかね？書いてあることは知ってることが多そうだけど、それをどうやって簡潔に濃く説明しているのかは気になります。
コメント