我々は設計し、構築した。 trustyou cxpプラットフォーム ゼロから作り、その過程で数々の設計上の決定を下す。.
複数の製品チームと 一時的なチーム 相互依存するサブシステムを並行して開発する中、エンジニアには迅速な行動のための高い自律性が求められる。しかし、方向性の統一を欠いた自律性は混乱を招く。自律性を促進しつつ方向性を維持する鍵は、進化するアーキテクチャを成長させる確固たる戦略にある。.
“「アーキテクチャ上の決定」とは、ソフトウェア構築における様々な選択を包括する総称である。本稿では、trustyou cxpプラットフォームのソフトウェア構造と技術ロードマップに関するアーキテクチャ上の決定を、我々がどのようにアプローチしているかについて、いくつかの考えを共有する。.
構造に関するアーキテクチャ上の決定：境界のあるコンテキスト
境界のあるコンテキストはドメイン駆動設計（DDD）の重要な概念だ。正式な定義は「赤本」と「青本」の両方に記載されているほか、優れた記事や資料も多数存在する。.
境界のあるコンテキストは、プラットフォームの構造に影響を与える我々のアーキテクチャ上の決定の基盤を形成してきた。我々はまずサブシステムを特定し、それぞれに対して境界のあるコンテキストを定義することから始めた。.
もちろん、我々の定義にはドメインモデルの普遍的な言語が含まれている。しかし、各コンテキストにおける入力データと出力データ、そしてアクションにさらに重点を置いている。.
我々は共通のテンプレートを用いて境界付きコンテキストを文書化し、それらを全てプロダクト＆エンジニアリング部門全体で共有するオンラインボード上にまとめて管理している。.
サブシステム間の境界とインターフェースの詳細に焦点を当てているため、境界付きコンテキストの定義は共同作業となった。エンジニア、チームリーダー、そして私が協力し、各境界付きコンテキストとその境界、インターフェースについて共通認識を構築したのだ。.
全プロダクトチームの代表者を集めてワークショップを開催し、以下の重要な質問に答えた：
- プラットフォームのサブシステムとは何か？
- 各サブシステムの目的と目標は何か？
- 各ドメインモデルにおける中核となるエンティティとオブジェクトは何であるか？
- それぞれの普遍的な言語は何だ？
- 各サブシステムの入力インターフェースと出力インターフェース、つまりデータとアクションは何か？
このトップダウン型のワークショップ手法は、部門ごとの孤立した考え方を避けるのに役立つ。また、隠れた前提を早期に発見し、より良い意思決定を可能にする。.
我々はシステムアーキテクチャを文書化するためにC4のレベル1とレベル2を使用している。境界付きコンテキストを定義すると、それらはシステムコンテキスト図の主要な入力として機能した。この図はサブシステム、外部依存関係とアクター、そして全てのインターフェース（内部・外部）を捉えるものである。あらゆるスケーリングする技術的決定を行うための強固な基盤となっている。.
主な要素は？協働、適切な対象者、そしてワークショップのための十分な時間だ。.
技術に関するアーキテクチャ上の決定：技術ロードマップ
trustyou cxpのアーキテクチャを形作る上で、技術的な決定は構造的な決定と同様に重要であった。.
我々は技術ロードマップを用いて、どのツールや技術、フレームワークを採用し、段階的に廃止し、評価しているかを議論し可視化する。実際、部門内の各チャプターごとに異なる技術ロードマップがあり、それぞれが独立して進化している。.
ThoughtWorksのテックレーダーが最も一般的な形式ではあるが、我々にとってはロジャースの技術採用曲線の方がより適していると判明した。.
当社の技術ロードマップは六つの段階から成る：
- 見つけろ
- 操縦しろ
- 設計せよ
- 採掘する
- 優先度を下げる
- 廃止する
各段階には、その段階にいる意味を明確にするためのガイドラインが付属している。これらの視覚的要素とヒントは、有意義な議論をサポートし、重複を指摘し、知識共有の機会を浮き彫りにするのに役立つ。.
新技術を評価したり代替案を比較する際には、明確に定義された範囲と成功基準でパイロットを実施する。その結果は文書化され、最終的な決定をサポートする。.
我々はCXPの実装を始める前から、これらのロードマップの最初のバージョンを作成した。そして今、年2回の更新を目指している。.
“「お前、客室平均単価（ADR）書かないのか？」”
要するに：もちろんだ。.
そう、我々はADRを書く。境界のあるコンテキストや技術に関する決定のためだ。だが、ADRは他にも多くの種類のアーキテクチャ決定に使う。.
とはいえ、全ての決定を客室平均単価（ADR）に押し込むわけではない。我々の焦点は、適切な人物と適切な対話を行うことにある。客室平均単価（ADR）が議論に付加価値をもたらし（決定を改善する場合）、それを文書化する。時には、少人数のグループによる迅速な決定がなされ、我々は直ちに実行に移ることもある。.
議論する、可視化する、feedbackを集める、反復する
結局のところ、確固たる原則とベスト・プラクティスを適用することこそが肝心だ。.
アーキテクチャはプラットフォームと共に成長するものだ。一度定義して永遠に固定するものではない。代替案を必ず探求せよ。トレードオフを明らかにせよ。技術系と非技術系のステークホルダー双方からfeedbackを得よ。そして最も重要なのは、, 意識的な決断を下す。.
物事は変わる。小さなことから始め、繰り返し改善し、完璧な解決策を求めて延々と議論に囚われるな。ネタバレ：二年後には何が完璧か、お前にはわからない。.
境界のあるコンテキスト、技術ロードマップ、そして客室平均単価（ADR）は、これらの原則に従うのに役立つ。おそらく君たちにも役立つだろう。.
