前置き
内容的には、前回の続きになります。
1. 「ドメイン」が異なる（ビジネス vs 運用）
あまりパイプラインアーキテクチャでドメイン駆動の思想が語られている印象がないのですが、なぜでしょうか？
実は、DDDの思想が生まれた「ドメイン（領域）」と、CI/CDパイプラインが生まれた
「ドメイン」が、歴史的にまったく異なるコミュニティに属していたからです。
ドメイン駆動設計 (DDD)
生まれたドメイン
複雑な 「ビジネスロジック」 を扱う、アプリケーションアーキテクチャの世界です。
関心事
「注文」や「在庫」といったビジネス上の関心事を、いかに正しく、変更に強くモデル化するか。
コミュニティ
ソフトウェア開発者、アプリケーションアーキテクトなどの団体。
CI/CDパイプライン
生まれたドメイン
ビルドやデプロイを自動化する、「オペレーション（運用）」 の世界です。
関心事
「ビルド」「テスト」「デプロイ」という技術的なプロセスを、いかに速く、安定的に実行するか。
コミュニティ
運用エンジニア、SRE、DevOpsエンジニア。
2つの領域の分断
上記のそれぞれの文脈での関心の違いなどから、歴史的に、この2つのコミュニティは
組織的にサイロ化されており、
異なる書籍を読み、
異なるカンファレンスに参加し、
異なる問題を解決しようとしてきたそうです。
ゆえに、認知領域で分断が起きてしまいやすい構造です。
2. パイプラインが「アーキテクチャ」として扱われてこなかった
パイプラインにDDDの思想を適用するには、まず
「パイプライン自体も、一つの複雑なソフトウェアプロダクトである」
と認識する必要があります。
しかし多くの現場では、パイプラインは「アーキテクチャ」とは見なされず、以下のように扱われてきました。
・単なる「自動化スクリプト」
・DevOpsエンジニアが管理する「ツール」
・一度作ったらめったにリファクタリングされない「秘伝のタレ」
DDDは、複雑な「プロダクト」を設計するための思想です。
そのため、パイプラインを「スクリプト」としか見ていないと、そこにDDDを適用するという発想自体が生まれにくいです。
3. 成熟度の問題（高度すぎる抽象化）
モノリシックなアプリケーションのための単純なパイプラインは、それほど複雑ではありません。
なぜなら、以下のように、１本の エンドツーエンドパイプラインモデル だからです。
ファンインパイプラインモデル
しかし、モジュラーモノリス構造が必要とされるあたりから、パイプラインの構造は
以下のように変わってきます。
パイプラインアーキテクチャが「DDDのような設計原則を必要とするほど複雑化」するのは、システムがマイクロサービス化・分散化し、パイプライン自体も分散化した後の、非常に成熟した段階です。
DDDとの一貫性
「パイプラインのコアドメイン（象限1）」や「OCPの適用」といった考え方は、アプリケーションアーキテクチャとパイプラインアーキテクチャの両方を熟知した上で、それらを統合しようとする高度な抽象化です。
結論
CI/CDパイプラインでDDDの思想が語られないのは、ほとんどの組織がまだ、その2つを結びつけて考えるほどの成熟度に達していないからのようです。
しかし最近、「プラットフォームエンジニアリング」 というワードが飛び交っています。
この流れは、まさに
「パイプラインや開発者向けインフラを、社内向けの “プロダクト” として設計・提供する」
という考え方そのものです。
この「パイプライン＝プロダクト」という認識が広まるにつれて、
「パイプラインにもDDDやOOPの設計思想を適用すべきだ」
という設計思想が、これからの主流になっていくと予測しています。