アーキテクチャについて考える会を開催してみた

こんにちは、Graciaのプロダクト部・エンジニアの大地です。

今回は「エンジニアチームの働き方について」で話が出てきたオフライン会で行った取り組みのひとつ、アーキテクチャを考える会について、どのようなことを行ったのか紹介したいと思います。

この会を開催した経緯

弊社のエンジニアチームでは、オニオンアーキテクチャを採用し、DDD（ドメイン駆動開発）のエッセンスも所々取り入れながら開発を行っています。これまでもアーキテクチャに関する技術書の輪読会を行ったり、コードレビュー等を通して、ある程度の共通認識を持って開発に取り組んできました。

しかし、日々の開発のなかで実装方針に迷いや人によってズレがあったり、新しいメンバーが入ってきたときに意識を揃えるのが難しいことから、過去に作成したコーディング規約をアップデートしたり、全体的なアーキテクチャが理解できるよう図に起こしておきたいという理由で行いました。

どのようにして進めたか

まず、メンバー各々が普段開発している中でよく遭遇する迷いポイントや疑問を書き出してもらい、課題をレイヤーごとにグルーピングし、ひとつずつ深掘りしながら方針を決定していきました。

議論したことをいくつかピックアップして例に挙げると

例外クラスはどこに置くのが正解？
RepositoryクラスとCakePHPのTableクラスの役割の違いは？
ぼくらがFactoryと呼んでいるものは本当にFactoryとしての役割を果たしている？
テストコードの対象は？（Getter、Setterとかはあまり書かなくてもよいよね）

等々です。

成果

ひとつひとつ議論した結果、最終的にはディレクトリ構成のアップデート・アーキテクチャ全体図のアップデート・コーディング規約のアップデートを行うことができました。

アーキテクチャ全体図のアップデート

より現状に即した（または今後目指したい）形で作成することができ、メンバーがシステム全体を俯瞰的に捉えるのに役立ち、各コンポーネントの相互関係やデータフローを明確に理解することができるようになりました。

ディレクトリ構成やコーディング規約のアップデート

日々の開発の中で、「このクラスってどこに置くべきなんだっけ？」とか「この処理はどの層で行うべきなんだっけ？」というような悩みを解決するための方針決めができたと思います。

会を開催してみて

議題によってはかなり白熱するものもあったり、なかには「境界づけられたコンテキスト」の話まで派生し、集約についてもう一度考え直す機会になったりと、メンバー全員がアーキテクチャに対する理解を深める機会となりました。オフラインで集まることで、普段のオンラインミーティングでは出てこないような直接的なフィードバックやアイデアの交換が活発に行われました。

そして、この会を通して、チーム全体として技術的な方向性と一貫性を確立することができました。個々人の技術的迷いを共有し、それに対する共通の解決策を見出すことで、日々の開発がよりスムーズに、効率的に進むようになりました。