こんにちは。イネーブリングチームでフロントエンド領域のリードエンジニアをしている鵜木(@nokki_y)です。
現在、開発生産性向上を目指しモチベーションクラウドのフロントエンド領域をリアーキテクトしています。リアーキテクトに至った背景はこちらの記事を覗いてみてください。 link-and-motivation.hatenablog.com 今回のリアーキテクトにあたりSoEとしての責務をバックエンド側からフロントエンド側に移行することになったので、この記事ではその背景をご紹介します。 株式会社一休のCTOである伊藤さん(Twitter)が、2016年に開催されたDevelopers Festa Sapporo 2016で発表した「System of Record と System of Engagment」の考え方を新アーキテクチャの設計で参考にしました。 ここではSoRとSoEの説明に主眼を置いていないため、その説明については上記の登壇資料を参考にしてください。
一応、要約された内容が株式会社一休のWantedlyにあったのでそちらの記事の要約だけここに貼り付けておきます。 システム、とひとことにいってもその目的が、例えば業務システムにおける個人情報の保存や確かな請求処理のように「Record (記録)」を主目的にしているのか、「使い易いユーザーインタフェース」のようにユーザーとの「Engagement (エンゲージメント)」を目的にしているのかで、実はそれぞれに適した開発手法や要件定義の仕方、もっと言えば対象システムのマネジメントの仕方が違うのではないか ･･･ という議論があります。
System of Record (SoR) には、案外ウォーターフォール的なやり方に代表されるような、事前に要件をきちんと見積もる方法が適している場面は少なくありません。一方、System of Engagement (SoE) ではそもそも正解が何かがよく分からないことも多いため、さっさと作り始めて トライ & エラーを繰り返す方がいい場面もよくあります。(その逆もあって、SoR なシステムに SoE 的な手法を当てはめることがうまい場面というのも当然あります。)
そして多くの場合は一つのシステムの中に System of Record (SoR) と System of Engagement (SoE) に相当する部分は混在している。その特性の違う部品が一つの中で混在している以上、SoR に向いたやり方、SoE に向いたやり方どちらか一方だけで対応しようとすると困難に遭遇しやすいのではないか。自社のシステム特性に合わせて SoR と SoE それぞれに対応できる力をバランス良く、組織として獲得していくべきではないか、ということを主張しました。 旧アーキテクチャではSoEとしての責務を一部バックエンドが担っていました。 というのも、旧アーキテクチャではUIに合わせたデータの変換(マッピング)をバックエンド側で行っています。この状態だと、UIを改修する際にバックエンド側での修正が必要となる可能性が高いです。そしてUIは多くの場面でユーザーとのエンゲージメントを高めるために改修されます。 つまり、ユーザーとのエンゲージメントを高める改修をする際はバックエンド側の改修が必要になるため、SoEとしての責務をバックエンドも担っていたと考えています。 その一方で新アーキテクチャは、UIに合わせたデータの変換(マッピング)をフロントエンド側で行っています。 これによりバックエンド側はUIに依存しないデータをレスポンスとすることが可能となるため、SoEとしての責務をフロントエンド側が担いやすくなりました。 こちらが旧アーキテクチャのデータフローのイメージ図です。ページ単位でUIと業務処理を分離しているので、各ページがデータにアクセスしています。フロントエンドで受け取るデータは、上述の通りバックエンド側でUIの形に変換されます。そして下記がUIデータ変換機能をフロントエンドに移した図です。 バックエンド側はデータ変換をせずにフロントエンド側にリソース状態のままデータを提供します。さらに進んで、新アーキテクチャのデータフロー図はこちらです。 新アーキテクチャでは、バックエンドから受け取ったリソースデータをドメインデータに変換してからUIデータにしています。「Resources Data -> Domain Data -> UI Component Data」の流れです。
バックエンドから受け取るデータはデータ間でのリレーションを保持しています。そのためRDBからのデータの取得ではありませんが、新におけるデータ変換機能をO/R Mapperと命名しています。つまりリレーションモデルのデータをシステム内でドメイン形式のオブジェクトデータにマッピングする機能となりました。 ※注釈 GraphQLを検証すべきでした。というのも、現状の新アーキテクチャは1つのドメインを形成するために複数のリソースデータをバックエンドから取得するケースがあります。これによりデータ取得待ちの時間が増えてしまうユースケースが発生しています。GraphQLだとGraphQLサーバでこの処理を担ってくれるため、ユーザーの待ち時間が軽減されます。 ユーザー体験をより良くするためにも、今後どこかのタイミングでGraphQLの検証を行いたいと思います。 今回、事業/プロダクト/組織等々の状況を考慮してSoE機能をフロントエンド側に寄せる方針としましたが、時と場合によっては旧アーキテクチャのような形になっていても良いと考えています。開発組織にバックエンドエンジニアが多い状況で短期的にコスト低く早く開発ができるアーキテクチャにするのであれば、旧アーキテクチャのようにバックエンド側にSoE機能があっても良いと思います。 アーキテクチャは効率的な開発を実現するためのものなので、(当然のことですが)その時の事業/プロダクト/組織の状況に合わせた設計が大事だと考えています。
「他の組織がこのアーキテクチャだから」「この技術が最近はやっているからそれを使う前提でこのアーキテクチャに」ではなく、目的に沿ったアーキテクチャ設計を今後も意識したいと思います。
# はじめに
# SoRとSoE
# 旧アーキテクチャおけるSoRとSoEの境界はどこにあった？
# データフローは具体的にどう変わったか
図から「業務処理」が無くなりましたが業務処理はUsecaseレイヤーで行っています。ページ単位で関心を分離する方法から(ある種ユースケース駆動)ドメイン単位で関心を分離する方法(ドメイン駆動)に変えた背景については、別記事にするのでこの記事では割愛します。# 反省点
# さいごに
