システム運用のドメイン駆動設計、または運用の抽象化（とりあえず背景「SIerの伝統的な運用」）の続きです。

こちらもご参照。
SIerの生き残り戦略としてのDevOps　システム運用の社葬から

あくまでもポエムですので、これら記事には今日から試してガッテンなお役立ち情報はありません。悪しからず。

#運用のとらえ方を考え直してみる

システム運用はすでにインフラ運用の領域までコード化されてきている
- 製品依存の「インフラ運用＝基盤運用」は技術的負債と認識され始めているのではないか？
- システム運用の技術的アドバンテージは製品に依存しないサービスデリバリ技術ではないか？
システム運用はシステム運用という業務ドメインである
- ドメインならドメイン駆動設計でモデル化できるのではないか？
- システム運用ドメインのエキスパートは運用者（部門）ではないのか？

こんなふうにとらえ直してみると、個別顧客に特化して最適化した運用業務から、運用そのものを抽象化して、小分けのサービスパッケージにすることで、

ほとんどの顧客にとって一定水準の価値を持つ運用サービス群を安価に提供する標準モデル
個別の顧客要望を柔軟に（素早く・安価に・追加のみで）標準モデルにアドオンできる汎用性

この二つを同時に実現できるのではないか？

#どんなモデルが欲しいのか？

運用者ではなく、運用の価値を売る（サービスの対価を得る）モデル
変化するシステム環境にもレガシーシステムにも同じ抽象化された**運用サービスの組み合わせ（濃淡）**で対応できるモデル
技術依存や顧客ルール依存をカプセル化し、ヒト前提ではなく抽象化されたロールによって事前に運用設計されたモデル

#イメージアップのとっかかり

ドメイン駆動設計についてはQiitaを読むような皆さんには釈迦に説法なので、解説はしません（というかできませんw）

もちろん、エリック・エヴァンスさんから始まって様々な方から学ばせてもらってますが、とくに今回の記事は、主に松岡さんの下記サイトからアイデアを拝借しています。ありがとうございます。

ドメイン駆動設計解説シリーズ

原点であるエリック・エヴァンスさんに沿って、ざっとブレイクダウンすると、

顧客の価値を中心に運用をモデル化できるのではないか？
- 顧客価値を生み出す運用業務の「オブジェクト」をドメインとするところから始める
  - ドメイン駆動設計を進めることによって顧客価値が鮮明になる（コアドメイン＝コアサービス）
  - 顧客価値（コアドメイン＝コアサービス）を最大化するドメインをモデル化する（汎用的サブドメイン＝実現サービス、強化サービス）
  - 顧客・ステークホルダー全体で同じ言葉で運用を議論する（ユビキタス言語）
安定稼働と変化を濃淡も持たせて両立させるモデル化ができないか？
- 運用業務のオブジェクト同士の疎結合
  - レイヤ化アーキテクチャ
  - リポジトリ
  - ファクトリ
- 運用業務のオブジェクト内部の高凝集
  - サービス
  - モジュール（パッケージ）
  - 集約
運用のロールとヒトを切り離したモデル化のあとでヒトの配置を検討できるのではないか？
- レイヤ化アーキテクチャ
- 腐敗防止層
  - 技術的負債のアウトソーシング

etc.etc.etc...

#ドメインを隔離する

というわけで、何はともあれここから始めてみようかと。
この場合のドメインとはもちろん、運用を業務としてみた「運用ドメイン」のこと。

これを隔離するとは、運用の本質を蒸留して抽象化しコアドメインとすることで、ITシステム全体をこのドメインに従わせるという野望の第一歩です。

##レイヤ化アーキテクチャ

もっともコアになるドメインを基礎にしてレイヤを設け、各々の責務と操作の方向を明確にし、レイヤ間を疎結合にして、ドメインの凝集度を高め、ドメインロジックの変更の影響を最小限にしようというアーキテクチャ。（お釈迦さま、これでよいでしょうか？）

###ITIL V3 （プロセスとライフサイクル）

まずは、ドメイン関係なく、よく見る ITIL のプロセスとライフサイクルの図。なんか中心が馬鹿でかいですが、後続の図の都合ですｗ

###ドメイン駆動設計（DDD）オリジナル

エリック・エヴァンスさんのDDDは、こんなレイヤ化アーキテクチャですよね。よくインフラストラクチャに左右されるからダメじゃんと言われたりするそうですが。

大事なのは、図にも書いた通り、「依存する」方向の矢印は、矢印の先の（下の）レイヤが決めるインターフェース（メソッド）でしか、上のレイヤから下のレイヤにアクセスできないということ。

###DDD（オニオンアーキテクチャ）

クリーンアーキテクチャとか、いろいろな考え方があるそうですが、そんなに厳密なことを言われても私がわからないので、これが運用のドメインモデルにピッタリくるという独断的な判断です。

###伝統的SIer（オニオン風）

伝統的なSIerのアーキテクチャをオニオン風に描いてみましたの図。
顧客の事業戦略のもとに顧客要件が決まり、顧客要件（機能要件）を満たすアプリケーションが作られ、アプリケーションが動く非機能要件をもとにインフラストラクチャが選択される、という依存関係です。ウォーターフォール型開発の説明をしているような感じですが。

###伝統的SIer 運用モデル＋ ITIL（オニオン風）

伝統的SIer（オニオン風）に、先ほどのITILライフサイクルを重ねてみましたの図。
おそらくこれが一般的な（とくにエンタープライズの）運用モデルであろうと思います。
この同心円のどこかに運用部門と開発部門の責任分界点があり、それより内側は運用にとってのブラックボックス、外側は開発にはよくわからない泥臭い運用、とここまでおつきいただいた方にはすぐにイメージできるかと思います。

###DDD（オニオンアーキテクチャ）運用モデル

いよいよ、DDDオニオンアーキテクチャの考え方を参考に、運用業務ドメインを中心に依存関係を逆転させた図。

顧客要件もインフラストラクチャもアプリケーションも、顧客のサービス戦略に依存するのは当然ですが、そもそもそれら全ては**「運用できるように構成しなければならない」**というジャイアンがのび太やスネ夫を従えるような見方になります。運用最強。

###DDD（オニオンアーキテクチャ）運用モデル＋ ITIL

そして、この運用唯我独尊モデルにITILライフサイクルを重ねるとこんな風になるという図。
絵心がないので補足しますが、依存関係を表す矢印はITILのどのプロセスからも、顧客要件、アプリケーション、インフラストラクチャでまず受け止めるイメージです。
例えば、新規システムを追加するサービストランジションはアプリケーションにだけにお伺いをたてるのではなく、インフラストラクチャや顧客要件ともご相談の上、新規システムを既存に追加することになります。ただし、顧客のサービス戦略やコアの運用ドメインに反しない限り。

なんて横暴なジャイアンと思われるかもしれませんが、そうではなく、逆にいろいろな要望や開発、技術の変化などのライフサイクルにも、運用ドメインから明確な「運用サービスの使い方＝インターフェース（メソッド）」を予め提示しておくことで、開発部門も素早く高品質で対応できるようになるはずだ、という思いです。

もし次があるなら、「ユビキタス言語」か「境界づけられたコンテキスト」を運用業務ドメインにあてはめたらを考えてみるのが面白いかもしれません。
あるいは「腐敗防止層」を技術的負債のシステムの運用に応用するのも楽しそうですし、運用自動化の際にすぐに陳腐化してしまう製品・ツール依存の手順をカプセル化するための運用抽象化というのもグッとくるものがあります。

というわけで、念のため繰り返しますが、以上の一連の記事は私個人の意見であり、所属する組織その他と関係するものではありません。