Sansanアーキテクチャ史とiOSアプリリニューアルに見る、良質なシステム設計の原則

「Sansan Builders Box 2019」レポート

　2019年10月23日。Sansanのものづくりに携わるメンバーを中心としたカンファレンス 「Sansan Builders Box 2019」が開催された。各セッションのうち、本稿では荒川聖悟氏による「Sansanアーキテクチャ史」と、中川泰夫氏による「Sansan iOS アプリのリニューアルの舞台裏 -VIPER を導入し、単一責任の原則にのっとったモジュール化された構造を実現する」をレポートする。創業以来、アーキテクチャの継続的な改善が続けられてきた法人向けクラウド名刺管理サービス「Sansan」。その足跡に見る「良質なシステム設計の原則」とは？

Sansanのアーキテクチャはどう変遷してきたか？

Sansan株式会社 Sansan事業部 プロダクト開発部 サーバーサイドエンジニア 荒川聖悟氏

　まずお届けするのは、荒川聖悟氏による「Sansanアーキテクチャ史」だ。法人向けクラウド名刺管理サービス「Sansan」は、約12年の歴史を持ったアプリケーションである。「Sansan」のシステムのアーキテクチャは、version1、version2、version3（以下、v1、v2、v3と表記）という変遷をたどってきた。

v1における各レイヤの役割

　v1は初期の頃に用いられたアーキテクチャであり、Web Formsを用いた設計がなされている。各コンポーネントについて簡単に解説すると、Web FormsがUIを担当するレイヤ、Business Logic Layerがビジネスロジックを対応するレイヤ、Data Access Layerがデータアクセスを担当するレイヤとなっている。

　「Web FormsはBusiness Logic Layerと対応しており、かつBusiness Logic LayerはData Access Layerと対応しています。Data Access Layerの内部ではSQL文を生成して、実行します。v1の利点はとにかく設計がシンプルであることです。すべてのレイヤが1対1で結びついており、画面と業務ロジックの対応関係が明確でした」（荒川氏）

　だが、企業の成長とともにv1のアーキテクチャに課題が見えてきた。Web Formsを主体として設計を考えているため、どうしても画面に密結合したロジックになりやすいのだ。各レイヤの責務が曖昧になり、結合度が高くなってしまった。

v2の概要

　この課題を解決しようと試みたのがv2だ。このアーキテクチャには大きく分けて、ビジネスロジックを担当するServiceレイヤ、モデルとO/Rマッピングを担当するDomain Modelレイヤ、データアクセスの抽象化を行うRepositoryレイヤが存在する。いわゆるドメイン駆動設計（DDD）ライクなアーキテクチャである。

　O/Rマッピングの導入は開発の利便性をもたらしたものの、同時に課題も発生した。Repositoryのコード量やモジュールが肥大化してしまったのだ。それに伴い、Repositoryを利用する側であるServiceの実装難易度も高くなってしまった。

　「いまふり返ってみれば、設計方針についての共通認識をエンジニア全員で持てていませんでした。また、O/Rマッピングによって発行されるクエリを解析することが困難になり、システムのパフォーマンスが出ないという問題にも直面しました」（荒川氏）

アーキテクチャの良い点、悪い点を正しく理解する

v3のアーキテクチャ図

　これらの課題を解決するため、v3（※注）のアーキテクチャが登場する。このアーキテクチャは、UIレイヤ、Applicationレイヤ、Domainレイヤ、Infrastructureレイヤという層に分かれている。

※注：正確には、Sansan社内ではセッション内で解説したアーキテクチャのバージョンをv3.5と呼んでいる。これはv3のアーキテクチャから、さらにマイナーチェンジを行ったものであることに起因している。セッション内では説明をわかりやすくする目的から、v3という呼称が用いられていた。

　フロントエンドが固有で発行するクエリ（基本的にSELECT文のみ）を、UIアセンブリ（モジュール）ごとにデータアクセスレイヤを持たせて配置している。その他のクエリに関しては、DataAccessorに置くことで共通化を実施。また、Applicationレイヤは「名刺」「企業」といった業務ごとの分割が行われている。

　ServiceとDataAccessorは1対1で対応する形となっている。Service内でトランザクション管理を行い、DomainレイヤであるDataAccessorのインターフェースを利用。そして、データアクセスの実処理は、InfrastructureレイヤであるDataAccessorの実装クラスが担う。これにより、データベースのテクノロジーに依存する実装を隠蔽しているのだ。

　また、v2で用いていたO/Rマッピングをやめ、クエリを文字列として組み立てる形をとっている。「Sansan」はその仕様上、テーブル結合が非常に多いため、クエリ発行する形の方がパフォーマンスチューニングを実施しやすいのだ。v3のアーキテクチャは全体的にシンプルになり、共通化のバランスが取れている。かつ、誰が見ても理解しやすい構成となった。

　「時代とともにアーキテクチャは変わります。ですが、v1やv2の頃に、そのアーキテクチャを選んでいたのには必ず理由があったわけで、単に批判をすることには意味がありません。何が良くて、何が悪かったのかを理解することが大切です。また、アーキテクチャを構想することと同じくらいに重要なのは、メンバーにその意図を正しく浸透させることです」（荒川氏）

　サービスの仕様や扱うデータの量、開発組織の規模など、ありとあらゆる要素に影響を受けて、最適なアーキテクチャの定義は変わる。だからこそ、「プラットフォームやアプリケーションに合わせたアーキテクチャを選ぶことが重要です」と荒川氏は結び、セッションは終了した。