> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/ja/2020/w27-domain-driven-design-and-frontend-backend-interaction-patterns.md). # W27-ドメイン駆動設計とフロントエンド・バックエンドの連携 #### **ドメイン駆動設計について考えたこと** **急速な変化の中で、どうプロジェクトの核を安定させるか。改善を重ねるうちに複雑さが制御不能となり、再設計に至る事態を避けたい。** すでに、業務知識がチーム内で伝わる途中で失われる問題に直面している。組織が大きくなり、人が入れ替われば、さらに深刻になる。**核とは何か。それは業務の理解と抽象化であり、ソフトウェア設計に写せば、ドメインに基づく設計だと私は考える。** フロントエンドより、バックエンドのほうが設計を詳しく、遠くまで考えることが多い。プロジェクトは業務への深い理解の上に築く必要がある。理解が深く、抽象化が徹底しているほど、保守性と拡張性は高くなる。ある意味では、バックエンドは設計なしに着手できない。 フロントエンドは少し違う。私たちの技術案は、個別の技術的要点や業務フローの実現に偏りがちで、業務を深く分解することが足りない。率直に言えば、**設計は基本的に、ページを実装する段階にとどまっている。** 業務を抽象化したうえで、コンポーネントやソフトウェアの階層を設計する例は少ない。 よいバックエンドのテーブル構造とservice層は比較的安定している。業務領域を深く理解し、抽象化した成果だ。加盟店側は今、業務が速く変わり、UIや操作もそれに伴って変化する時期にある。どうすれば変わらないものを使って、多くの変化に対応できるか。全体として、より低い費用で事業の成長を支えられるか。ドメイン駆動設計に答えを探したい。 決済画面を例にする。今回のi版の再設計では、コンテナーコンポーネントと表示コンポーネントで全体を構成した。前者は状態管理と業務ロジック、後者はデータをビューへ写すだけの純粋なコンポーネントを担う。業務ロジックはそれほど複雑ではないが、それでもコンテナーは600行余りになった。今はすっきりしていても、まもなく融資払い、資産運用資金による支払い、マーケティングなどが加わり、厚くなる。どうするか。分割するしかない。何を基準にするか。ドメインだ。決済画面の核は支払い方法の扱いなので、業務属性が異なる支払い方法をドメインとして抽象化すべきだ。方法ごとに資産の提供者が異なり、一つの領域と見なせる。それぞれ固有の属性と動作を持つ。クイック決済ならカード一覧という属性、カードを選んで暗証番号を入力する動作がある。融資払いなら分割回数や金額という属性、顔認証で借り入れる動作、融資契約を取得する動作がある。これは業務ロジックの下層で、比較的安定している。将来UIがどう変わっても、プロジェクトの核であるドメイン層は変わらない。VueからReactへ技術スタックを変えても、核を安定したまま移せる。 設計は私自身もこれまで弱かった。ドメイン駆動設計の構想を、さらに議論し、ぶつけ合いながら育てていきたい。 #### **フロントエンドとバックエンドのデータ連携について** ウォレットと比べ、決済側のAPI連携には明確な設計上の違いがある。決済画面、カード紐付け、支払いなどでは、フロントエンド向けAPIがほぼページ単位で設計されている。API間の関係も、人が画面を操作する順序に沿っている。前のAPIが次のAPIのURL、リクエストパラメーター、現在のページに必要なすべてを返す。あとは描画済みのページを直接返すだけ、というほどだ。 よい点は、フロントエンドの役割が人と画面のやり取りにほぼ集中し、単一に見えることだ。バックエンドは連携を柔軟に制御し、次のAPIを自由に決め、異なる下流を呼び出してデータを返せる。フロントエンドと調整する手間を避けられる。 悪い点も明確だ。この方式はAPIとビュー、あるいは人の操作フローを強く結合し、拡張性は脆い。この連携が成り立つのは、ビューと業務フローが十分安定しているからだ。実際、決済業務はその前提に比較的合っている。汎用性は弱いが、最初からこの構造を選んだ以上、深い考慮があったはずだ。今のところ、決済という場面で絶対によいとも悪いとも言えない。業務を進めながら理解したい。 **クイック決済では、API Aが次に呼ぶAPIを返し、その後の経路を決める。バックエンドはフロントエンドのバージョンを知る必要がある。バージョン番号を使うか、顧客IDを手がかりに全経路で段階配信を行うか、いずれかが必要だ。**