「マイクロサービス設計」と「クリーンアーキテクチャ」の思考の違い

「マイクロサービス設計」と「クリーンアーキテクチャ」の思考の違い

最近めっちゃ忙しく気づくと1月中旬から4月1日までブログ更新なし。
「ブログ書く暇あるならコード書け！」と自分に鞭打つくらい慌ただしい日々が続いてました。

なぜか？

抱えていた案件の納期が2つとも3月末だったのです…。
そりゃもうラストスパートに向かい段取りしてましたけどね、最終チェックで仕様変更がボロボロと出てきて「えっ！その変更も含めて3末!?」というね。まぁ何とか熟せたのでとりあえず一安心です。

タイトルに掲げた2つの思想について

今回の現場ではそれぞれに異なった設計思想がありました。
それがマイクロサービス設計とクリーンアーキテクチャです。
正直いって、この2つの違いに悩み戸惑い頭が混乱してたんですよね。

という事で、今回はこの2つの設計概念について今回行なっていた頭の中の整理方法をまとめて置こうとの趣旨の内容となります。

2つの思想の概念を整理

まずはそれぞれの概念的な文書をコピペしてみます。

マイクロサービス（英語：microservices）とは、ソフトウェア開発の技法の1つであり、1つのアプリケーションを、ビジネス機能に沿った複数の小さいサービスの疎に結合された集合体として構成するサービス指向アーキテクチャ（service-oriented architecture; SOA）の1種である。

by Wikipedia

クリーンアーキテクチャはRobert C. Martin(Uncle Bob)が2012年に提唱した、DBやフレークワークからの独立性を確保するためのアーキテクチャである。

by 参照GitHub

これだけでは何が何だか理解できないですよね。
もう少し具体的に記載すると、2つのやりたい事は同じで「どこに何が記載されているか理解し易く整理しましょう」という事になります。
その指針として「どうまとめる？」で2方向の思考があると理解すると腑に落ちるのが早いかもしれません。

2つの思想の相違点

正確に言えば、この2つの方向性は決して競合関係にあるわけではありません。
ただし、何を主眼にするかで多少書き方が変わってきます。

マイクロサービス設計

ビジネスのサービス（何をするか）に注目して記載箇所を切り分けます。

ECを例にしてみます。
ECを考えると購入者側の機能として最低限必要な4つのサービスが浮かび上がります。

これらを【商品検索機能】【商品詳細表示機能】【カートBOX機能】【決済機能】として機能別にコードを取りまとめ管理していきます。

クリーンアーキテクチャ

マイクロサービスでは機能を利用者が受けるサービスという視点で切り分けました。
これをシステム的な視点で切り分けて記載する箇所を明確にする（どこに何があるかを明確にする）のがクリーンアーキテクチャになります。

上記ECの例をクリーンアーキテクチャ的に切り分けてみます。
商品検索をする場合、その中では次のような作業をする必要があります。

この作業、商品表示でも同じですよね。
こんな感じでプログラム的な機能で切り分けて「◯◯は××に記載する」とルールを決め整理するのがクリーンアーキテクチャです。

マイクロサービス×クリーンアーキテクチャ

競合する概念ではないため、当然このようなハイブリッドな仕様も存在します。

突き詰めていくと、DDDのような構造になるのかな。ここら辺の理解はいまいちですが、DDDではアプリの提供する機能を【モデル】と捉えシステムはモデルベースで構成されるべきだと概念設計されているそうです。

ドメイン駆動設計（英: domain-driven design, DDD）とはソフトウェアの設計手法であり、「複雑なドメインの設計は、モデルベースで行うべき」であり、また「大半のソフトウェアプロジェクトでは、システムを実装するための特定の技術ではなく、ドメインそのものとドメインのロジックに焦点を置くべき」である

by Wikipedia

概略だけだとモジュール的でマイクロサービスっぽく聞こえますが、モデルに属さない機能はサービスとして捉えることやドメインオブジェクトを取得するメソッドはリポジトリだよねなど、内部を多層アーキテクチャで設計管理する事で見通しの良いシステム（可読性の高いシステム）を構成しようとしています。

2つの思想が共通して解決したい事

「難しく考えるとどこまでも難しくできてしまう」のがこの手の設計思想の問題点ですが、解決したいことは明確です。

そのためのルールが【マイクロサービス設計】だったり【クリーンアーキテクチャ】だったりするわけです。

最近クリーンアーキテクチャが増えた理由

マイクロサービス設計を行うためには、システム全体の見通しが必要です。
それがなければ『機能をどう分ければ良いか』の最適解は見出せませんよね。

でも、開発現場ではアジャイルがもてはやされ、しっかり細部まで設計された状態でコーディングする現場はほぼありません。
これは開発にスピードが求められているからであるし、市場の変化が早いからそうせざるを得ないという明確な理由があります。
そうなると、小さな機能をマイクロサービスと捉え、その中でクリーンアーキテクチャな実装をしていけばハイブリッドな仕様が出来上がりますよね。

コードの中をサービスごとに綺麗にディレクションすれば、何がどこに書いてあるか探す手間が大きく減ります。つまりは、人を変えても開発ができる状態になり、アプリをバージョンアップし続けることができる様になります。
つまりは、クリーンアーキテクチャでコードを書かない理由がどこにも見当たらないわけです。

MVCモデルとは何が違うのか

実際のところ違いはありません。
MVCモデルのModelとControllerの役割をさらに細分化しどこに書くかを明示したものと捉えていればほぼ正解です。

クリーンアーキテクチャは難しい？

慣れは必要だと思います。そして、良き指導者も必要です。
記載場所が違うと全体崩れますし「私にとってこれはリポジトリだ」なんてのがまかり通ってしまうと結局整理整頓できない状態ですよね。なので、最終的には現場合わせになるのだと思います。

現場合わせと言いながら基本はもちろんあります。

このほかにも Trait　を利用することもありますし、Validationディレクトリを用意して管理することもあります。
「これが正解」ではなく、理解し易く、コード全体の見通しをよくする事が目的なので、それぞれの現場に合わせた設計に合わせることの方が重要です。

まとめ

私は今回クリーンアーキテクチャでかなり手こずりました。
理由は、私が今まで書いてきたコードと大きく違ったからです。

私は「顧客に提供するサービスを小割りしてLibraryやTraitに収める設計」を主にしてきました。
そうすると、それぞれのLibraryやTraitにDBにアクセスする機能が入り込みます。
コードレビューの際にこれを大きく指摘され、めっちゃ修正したんですよね。

そこからクリーンアーキテクチャと向き合い2ヶ月。
やっと記載する場所の目星がつくところまで辿り着いた感じです。
こういう経験すると「まだまだだなぁ〜」と実感しますよね。

まだまだと感じるということは伸び代もあるという事！
今日もコーディングがんばっていきましょう！