約1年間の構想と実装期間を経て、担当事業のKenCoMがリニューアルオープンしました。今回の発表には、その過程で向き合った課題・解決したテクニック、DDDの統合を盛り込んでいます。【公開資料】：サービス開発における フロントエンド・ドメイン駆動設計の実践

いま、フロントエンド・エンジニアには、SPAを筆頭にリッチクライアントと呼ぶに相応しい実装が求められています。私の担当事業に限った話ではなく、フロントエンドの状態管理（データバインディング技術・データフローアーキテクチャ）は、次のステージに移行している様に感じています。

従来バックエンドが抱えていた複雑さの取り扱いが、フロントエンドに移行してきているのは間違いないでしょう。DDDは言語不問のアプローチであり、プログラミングのためだけのもではありません。この一角をコードに反映させることで「アプリケーションが複雑に変化していっても破綻しない」そんな指針を示してくれます。

本稿では発表に盛り込めなかった、いくつかの補足を綴りたいと思います。

レスポンス面でのボトルネックに、非同期処理の待ち時間と、いつ・どの条件でリクエストするか？というものが有ります。具体的なコードはここでは示しませんが、現在抱えている状態から少し先読みをして、裏側でリソースを取得する実装を今回導入しています。これはコード最適化というよりも、アイデア(戦略)と言えます。

ViewComponent に密に依存するリクエスト処理では、この戦略を立てるのは難しくなります。そのため、この戦略を支えるのはドメインモデルとドメインサービスということになります。

戦略を盛り込む余地は、様々なメリットをもたらしてくれます。例えば、より多くの状態を抱える様になり、オンメモリしている状態を適宜解放する必要が出て来た場合も、この機構は役にたつと思います。

ドメインモデル・ドメインサービスなど聞きなれない存在に、戸惑いを持たれるかと思います。これが必要かどうかは、プロダクト要件次第としか言い様がなく、各々が向き合う課題です。コードの断片だけで判断すると「この構成は複雑すぎるのでは？」と感じるかもしれません。そのため「向き合っている課題はどこまで複雑なのか？」という観点を語らずして、技術の啓蒙は成り立ちません。

モデルライブラリは現在過渡期とも言える状態で、immutable.Record が今回の構成で最適解であり続けるとは言い切れません。そのため、ライブラリ特有のAPIがView層など外に漏れ出さない様に、getterは関数化しておくなど、腐敗防止策を施しています。

書いては壊して、の繰り返しだったフロントエンドコード。今回取り組んだリニューアルではバックエンドコードを殆どを改修せずに済みました。珍しくもない事例ですが、これが成り立つのは技術と関心事が分離されていたからです。フロントエンドコードも、内部で技術と関心事の分離をして、次のステップへの影響を最小限に留めよう、ということもまた伝えたい内容になっています。

ReactなどのView層に特化したライブラリを差し替えるのであれば、ゼロからコードを書き始めることになり、ここに掛かるコストは不可避です。そのため、View層が剥離し易い状態が良しとされるのは、昨今の潮流を鑑みても議論の余地は無いと思います。ReactNative などによる守備範囲の増加により、コードの再利用・一元管理需要は増しています。バックエンドのAPIを共有するのと同じ様に、クライアントコードがクロスプラットフォーム間でドメインコードを共有するという UniversalJS を見据えるのは、自然な流れだと思います。

javascript でも css でも、いかにリファクタし易く影響範囲を特定出来るか？という設計観点は、長期運用案件の立ち上げ時には必ず考慮しなければいけません。

この観点から今回は MobX ではなく Redux を選択しました。しかし、同じ構造を MobX でも構える事は可能で、複雑な実装にも耐え得ることをここに綴っています。実践を経て、DDDのモデリングパターンは、特定の技術を超えたフレームワークとしての強み示してくれると確信しました。

サーバーサイド・ネイティブアプリ界隈では、このアプローチをコードに反映させる議論が何年も前から盛んに行われています。ベストプラクティス・サービス層の失敗事例など、フロントエンドでもDDDを採用するのなら、学ぶべき先人の知恵は進んで取り込むべきです。原典になっている下記の書籍も、是非手にとってみてください。

エリック・エヴァンスのドメイン駆動設計（通称・DDD本）
実践ドメイン駆動設計（髙木正弘 ヴァーン・ヴァーノン）（通称・IDDD本）

昨今のフロントエンド界隈ではもっぱら、コード最適化によるパフォーマンスチューニングが関心事かと思います。これは、啓蒙されている方々の主戦場がモバイルブラウザを対象とされていることが大きな理由かと思っています。もし本稿をご覧頂いている方の主戦場がモバイルブラウザであるのなら、今回ご紹介しているモジュール構成はよく検討されることをお勧めします。

例えば、immutable.js は Record と List しか利用していないにも関わらず、tree shaking に対応していないため、50KBほどファイルが肥大します。これは、数msの初期ロードを争うメディアサービスなどの現場では無視できないボトルネックになり得ます。

資料には明記していなかった、今回の私達の主戦場は以下のとおりです。

• PCブラウザのみに向けられていること
• アプリケーション色が強いこと
• クローズドサービスであり、SEO不要であること

どんな案件にも適合する、銀の弾丸と呼べるモジュール構成・アーキテクチャは今のところ存在せず、何らかのトレードオフと向き合わなければいけません。本稿がこれらの多様性の中に立たされているフロントエンドの皆様への一解となれば幸いです。