見出し画像

サーバーサイドのアーキテクチャにADRパターンを導入してから1年半が経過した

赤星孔太 / 株式会社助太刀

こんにちは。
助太刀開発部のEMをしております赤星です。
弊社のバックエンドはPHPで書かれているのですが、前回リアーキテクチャしてからおおよそ1年半経過したので、所感をまとめたいと思っています。

1. 自己紹介

株式会社助太刀の開発部のエンジニアリングマネージャー
事業部とのやり取りやpjm、開発効率化を担当
以前はオンライン英会話のiOS / バックエンド を担当
最近はポーカーにハマっています

2. 簡単に助太刀の説明

建設業界には330万人以上の職人がいるにも関わらず工事会社では「職人不足で大きな現場が受けられない」、「閑散期に仕事が欲しい」といった課題に悩まされています。助太刀アプリでは、工事現場の発注者と受注者を繋げるマッチングプラットホームを提供しています。

業界の課題やプロダクトのポテンシャルについてはこちらに詳しく書かれているので、よろしければ御覧ください。

3. 技術スタックとスコープ

助太刀のバックエンドはPHPで書かれており、Laravelを使用しています。構成は現在モノリシックになっており、すべてのAPIが1つのレポジトリで管理されています。今回はそのAPIサーバーのアーキテクチャについて説明します。

助太刀のAPIサーバーはADR パターンを採用しています。
ADR(Action-domain-responder) とはソフトウェアアーキテクチャパターンの1つです。MVCとは違い、1つのController や Serviceに処理を書いていくものではなく、各エンドポイント毎にリクエストからレスポンスまでファイルを分けて書いていくものになっています。
イメージを書いてみました。


ディレクトリ構造は以下のイメージです。
※ 実際のファイル名ではありません
※ 一部省略しています

├── app
├── Contracts // modelへのアクセス方法を定義しています。
　　　　　　　　　└── ProfileInterface.php
├── Domains // 実際のビジネスロジックです。
　　　　　　　　　└── ProfileGetDomain.php
　　　　　　　　　└── ProfilePostDomain.php
├── Http
　　　　　　　　　└── Actions // RouteからActionが呼ばれます。Domainに処理を渡します。
　　　　　　　　　　　　　　　　　　└── ProfileGetAction.php
　　　　　　　　　　　　　　　　　　└── ProfilePostAction.php
　　　　　　　　　└── Requests
　　　　　　　　　　　　　　　　　　└── ProfileGetRequest.php
　　　　　　　　　　　　　　　　　　└── ProfilePostRequest.php
　　　　　　　　　└── Responders
　　　　　　　　　　　　　　　　　　└── ProfileGetResponder.php
　　　　　　　　　　　　　　　　　　└── ProfilePostResponder.php
　　　　　　　　　└── Repositories // modelへのアクセスを行う部分です。
　　　　　　　　　　　　　　　　　　└── ProfileRepository.php
├── bootstrap
├── config
├── database
├── lib
├── node_modules
├── public
├── resources
├── routes
　　　　　　　　　└── api.php // 管理するサービスにより別れています
├── storage
├── tests
└── vendor

4. 採用理由

元々フレームワークはLaravelを採用しており、MVCで実装していました。
実装して様々な改修を重ねるうちにサービス層が肥大化してしまい
- 可読性が下がり、不具合の調査に時間がかかる
- 改修が予期せぬ部分に影響を与えてしまう
という問題が発生し「エンドポイント につき、1アクション 1メソッドで整理できる」ことにメリットを感じるようになりました。
新しいプロジェクトが始まるタイミングで、改修を加える新機能がドメイン的に独立していたので、その部分から徐々にADRに移行するようにしていきました。

5. 導入してみて

【GOOD】メリットは享受できた
ADRを導入したことにより、上記の課題は緩和されたように思います。APIのエラーが発生してることを検知後、原因の箇所に当たりをつけるスピードは格段に上がりました。また「1アクション 1メソッドで整理している」ので他の箇所に影響が少ない、という安心感のもと開発できるようになりました。


【GOOD】テストコードが書きやすい
弊社の市川さんの記事にもありましたが、サーバーサイドのテストコードをあまり運用できていませんでした。この半年の間テストコードを拡充やCI等運用を構築していったのですが、ADRにより責務が細かく分かれる設計になっているので、その責務ごとにテストを書くことができました。


【BAD】ファイルをつくるの大変
メリットとデメリットが表裏一体なのですが、ファイルによって細かい責務が分かれている為、たくさんのファイルが出来てしまいます。
簡単な値を返すエンドポイントを作成する場合でもActionファイルやDomainファイルなど、それぞれファイルを新規作成する必要があり、細かい新規作成機能であろうと、初速が出ないことはデメリットです。
ただ、artisanでファイルを自動生成するコマンドを作成することで多少解消されました。


【BAD？】結局ドメイン駆動開発を取り入れないと、この設計のメリットを最大限活用できない
ADR は1つのActionから1つのResponder でシンプルに定義ができるというところがメリットだと思うのですが、本来のADRの利点を取り入れるにはドメイン駆動開発を取り入れないといけないと感じています。
現状ドメイン部分にビジネスロジックを記述しているのですが、Laravelのmodelを使っているだけで、正しいドメイン知識でモデリングされていません。
弊社のサービスでいうと、主要サービスであるマッチングの他、求人サービスや金融サービスも存在しているので、それに合うようにドメイン部分を設計していきたいと考えています。


6. 今後どうしたい

アーキテクチャのデメリット自体は仕組みで解決できる部分が多く、今の所再度リプレイスする必要には駆られていません。
但し、そもそものモノリシックによるデメリットは発生してきているので、マイクロサービス化をスモールスタートで始めていきたいと考えています。
またある程度知見がたまりましたらまとめようと思います。


7. スモールスタートでいろんな改善をする仲間を募集してます

以上、つらつらと所感を述べてきましたが、伝えたいことは、一緒にこういったことを「どう設計しましょうかね…」と悩んでくれる仲間を募集しています、ということです。
助太刀が立ち向かう建設業界のという市場は、規模60兆円を超える巨大市場にも関わらずICT化が進んでいない、という課題を抱えています。それを一緒にテクノロジーの力で解決するプロダクトを一緒に作っていきましょう。

▼助太刀の情報はこちら
https://note.com/sukedachi/n/nb0893a5cc424
▼募集中の求人一覧
https://herp.careers/v1/sukedachi


この記事が気に入ったらサポートをしてみませんか？