天の月

ソフトウェア開発をしていく上での悩み, 考えたこと, 学びを書いてきます(たまに関係ない雑記も)

freee Tech Night in Kansai「モデリング重視のRails開発」に参加してきた

freee-tech-night.connpass.com

こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。

会の概要

以下、イベントページから引用です。

今回のテーマは「モデリング重視のRails開発」です。関西支社のメンバーが中心になって作っている「freee販売」の開発では、Ruby on Railsを使いつつ、モデリングアーキテクチャに工夫を加えています。今回は関西支社からの開催で、freee販売の開発メンバーにお話を聞いてみます。

会の様子

freee会計のRailsアーキテクチャ

通常のRailsだとController/View/(Active Recordで作られた)modelが近しいところにいるのが通常多い印象がありますが、Presentationが上にあり、真ん中にドメインモデルがあり、下にインフラがある三層アーキテクチャに近い構造を取ってきているということでした。

このようなアーキテクチャにするならRailsにする必要ないのでは?というツッコミはよく受けるそうですが、長年freeeさんで培ってきた厳しいセキュリティ要件に耐えられるだけのライブラリを再利用できるメリットがあるため、このようなアーキテクチャになっているそうです。

実際中途で入られたkakkinさんの目線でも、自分が知っているRailsとは全然違うぞ...となったそうで、特にmodelのディレクトリが2ついる*1アーキテクチャには戸惑ったそうです。

開発スタイル

ざっくりいうとオニオンアーキテクチャに近いアーキテクチャ×DDD*2が開発スタイルになっているそうです。

また、品質特性の中ではテスト容易性を重視したということで、カバレッジが100%に近い膨大なテストがある中でもテストが開発を早められるようになっているということでした。

開発の中では、名前づけを超重要視しているということで、開発者全員で複数のユースケースを考えてモデルの名前を変化させるスタイルを取っているということです。(腹落ちできないモデルの場合はコードをすべて捨てることも厭わない)

ドメインオーナー(ドメインエキスパート)

上記の開発の中では、PM/PdMがドメインオーナーを努めているということで、ドメインオーナーはドメインや販売に関してめちゃくちゃ詳しい猛者が揃っているということでした。

モデリングを常時しているメリット

開発者20人が全員同じ共通言語を持っており、設計が安定し、破綻しづらいアーキテクチャになっているということでした。

他にも、開発者が自分たちで見つけたものを自分たちで作っていくような感覚に陥るため、モチベーション向上に繋がるということでした。

モデリングを常時しているデメリット

コードを何回も書いては捨てる関係で短期的にはすごく時間がかかるように見える点はデメリットではないかという話がありました。

今後取り組みたいこと

最後に、パネラーの方からそれぞれ今後取り組みたいことに関して話がありました。以下、内容を常体で記載していきます。

  • 使っている人同士が接続できるのにシステム都合で接続できないことがあるので、freeeを使用している人は全員がつながるような仕組みを作りたい
  • 自分で販売を使ってみようと思っている
  • クライアントに同じ販売管理をしている会社は一社もないのだが、モデリングをすることで共通プラットフォームを作れるようにしたいとは思っている

Q&A

モデリングの中でER設計はするのか?

あんまりER設計を意識はしていないということでした。大事なのはモデルを作ることであり、図を作ることではないと考えているそうです。

ドメインエキスパートの人はモデル図ベースで議論できるのか?

ドメインエキスパートは全員エンジニアリング能力高いので、モデル図やER図を見てレビューができるということでした。

複数拠点での議論をどう進めているか?

基本はオンラインなので問題ないが、最近はモデリング合宿をチームでやったりしているということです。

Rails以外の言語は使っているのか?検討などはしたのか?

Goも候補に挙がったりはしているが、これまで溜まってきた資産を考えるとRails一択の現状になっているということです。

開発者全員の認識を揃えるのに時間はかからないのか?

基本的には全員が参加しているので、時間はかからない。全員が参加しない場合は、結果を全員に共有する時間を設けるようにしているということでした。

会全体を通した感想

教科書にしたがってできていてすごいなあと思いながら最初は聴いていたのですが、途中から、教科書的な内容にしたがうというよりはそれぞれが「これいいよね」と合意できるものを取り入れた結果教科書的な内容になっていったという話があったのが一番の驚きでした。

*1:Active Recordが強力なので、依存を避けるためにActive Recordに依存したmodelと依存していないmodelにディレクトリを分解することで、機能拡張をやりやすくしている

*2:ただし俺流DDDが多いので、社内ではDDDと言わないようにしている