2社の顧客がともに「active」という項目を持っています。一方は過去1年に購入した顧客を意味し、もう一方はサービス契約が有効な顧客を意味します。共通のコネクターは両方の項目を正しく運べます。しかし同じ業務状態として扱う共通規則は、一方にとって誤りになり得ます。これは説明用の例であり、導入事例の報告ではありません。
共通基盤と現場への導入に関する対談では、基盤の多くを再利用しながら、顧客ごとの環境でも相当な作業をする企業を紹介しています。そこでの割合はその企業固有です。一般化できる構成上の問いは、共通の仕組みがどこで終わり、現場の意味がどこで始まるかです。
転送の契約と業務の契約を分ける
転送の契約では、元システムへの認証、変更記録の読み取り、識別子の保持、安全な再試行、障害の可視化を定められます。これらの振る舞いは1度実装し、繰り返し試験できます。どの連携にも信頼できるデータの経路が必要なので価値があります。
業務の契約は、どの記録が正本か、ステータスが何を意味するか、いつ行動してよいか、誰が誤りを修正できるかを定めます。
- 共通の転送 識別・再試行・イベント ID
有効なイベントを届ける
- 現場の方針 意味・同意・時刻
行動の可否を決める
- 許可された行動 書き込み・監査
結果を記録する
業務の契約はワークフローに依存します。別の顧客と同じ元システムと送信先を使っても、異なる答えが必要かもしれません。
店舗とメールの接続を考えます。基盤はイベントの取り込み、重複排除、監査履歴を提供できます。ワークフローの担当者は、「購読中」が特定のマーケティング目的への許可を意味するか、購入でカート通知を抑制するか、同意の変更が送信待ちメッセージにどう影響するかを定めます。項目名から推測できるコネクターの機能ではありません。
以下のTajoの概念図では、3項目をそのままコピーします。ただし、販促の許可を定める行はありません。データ転送の仕組みは再利用できても、どの状態でどの行動を許すかはワークフローの担当者が決める必要があります。整った表は、その欠落を示せても埋められません。
実行前に同期を確認
顧客の更新をメール配信サービスに同期してください。
顧客同期
| 元のフィールド | 送り先のフィールド | ルール |
|---|---|---|
email | EMAIL | そのまま |
first_name | FIRSTNAME | そのまま |
last_name | LASTNAME | そのまま |
合成データでのプレビュー成功
3項目を対応付け · 送り先への書き込みなし
Tajoの対応付けツールを基にした概念図です。合成データでのプレビューや保存した下書きだけでは同期は有効になりません。
| 共通層 | 現場の層 |
|---|---|
| 認証とトークン更新 | 誰がこのワークフローへアクセスできるか |
| イベント転送と再試行 | どのイベントを業務上の状態変化と数えるか |
| 安定した識別子と重複排除 | どの記録が同じ実在顧客を指すか |
| ログと復旧手段 | 誰が争いのある状態をどう解決するか |
| 契約の検証 | 項目値の意味と行動に使える条件 |
この表は設計上の境界であり、すべての実装がこれほどきれいに分割できるという主張ではありません。
意見の違いを隠すと再利用は壊れる
汎用基盤は例外のたびに設定項目を増やしがちです。初めは再利用を保つように見えます。しかし後には、設定が技術的な選択、法的な制約、業務上の決定のどれか分からなくなります。共通の中核が、所有していない選択を遠隔操作する装置になります。
安定した不変条件を探します。「同じ元イベントを同じ送信先記録へ2回適用しない」は共通エンジンに置けます。「顧客が有効になったら割引を送る」は、「有効」、許可された対象者、特典方針の担当者を決めるまで共有できません。エンジンは承認された方針を実行できても、発明すべきではありません。
保守にも役立ちます。API が変わったら、基盤チームがアダプターと試験を更新できます。対象顧客の定義が変わったら、業務担当者が転送を書き直さず方針と試験例を更新できます。明確な境界があれば、それぞれの変更が権限を持つ人に届きます。
意味を平らにせず仕組みを再利用する
現場固有の規則には費用がかかるものもあります。再利用可能な契約がない基盤は、特注スクリプトの集まりになります。繰り返される意味を抽象化する前に、繰り返される仕組みを見つけます。共通の基本要素は、型のある条件、イベント時刻、行動の上限を受け取れますが、条件の業務上の定義は現場に残せます。
境界は実例で試します。通常のイベント、重複、遅れた修正、取り消された権限を用意し、それぞれどの層が応答するか尋ねます。障害をどの層にも割り当てられないなら、抽象化が責任を隠しています。新しい顧客のため共通の「active」列挙値に無関係な解釈が増えるなら、その共通型は広すぎます。
関連する導入の記事は実際のワークフローで能力が動くかを調べます。ここでは、仕事の意味を消さずに1度作れるものは何かを問います。
層の境界にあるインターフェースは、誤った前提を拒めるほど明確であるべきです。共通エンジンは行動依頼を受ける前に、イベント ID、元の時刻、行動者、申告された目的を要求できます。現場のワークフローは、その行動を許すか決める方針を渡します。目的が欠ければエンジンが拒否し、方針が曖昧なら現場の担当者が解決します。汎用コードに業務上の権限を押し付けず再利用する実用的な方法です。契約には受け入れる例と拒否する例を1つずつ記し、どちらかの層が変わるたびに両方を試します。
再利用できるコネクターは、現場の意味を表現しやすく、安全に実行できるようにすべきです。同じ項目名だけを理由に、異なる2つの約束を同一に見せてはいけません。
よくある質問
連携基盤は通常何を再利用すべきですか？
根本的な要件が一致するなら、認証の方式、転送、冪等性、再試行、ログ、契約の確認など、安定した仕組みを共有できます。
各事業に固有のまま残すべきものは何ですか？
項目の意味、正本となるシステム、同意の規則、時刻の要件、ステータスを基に行動できる人は、その事業とワークフローごとに定めます。
境界をどう試せますか？
既存の基本要素を使って新しいワークフローを表してみます。それで業務上の意味が変わるか、例外が汎用設定の中に隠れるなら、そのロジックは現場に残し、境界のインターフェースを明示します。