onemuri.space

クリーンアーキテクチャ

クリーンアーキテクチャって何がいいの?

私は、クリーンアーキテクチャは最初は実装面倒だなって思うけど後になってじわじわとええやん!ってなるアーキテクチャだと思ってます。

何が???

となるのは当たり前なので、もう少し具体的にいうと

インターフェースやドメイン、インフラのロジックを 明確に境界を分けて、テストをしやすくしたりデータベースに依存しないようにしたりするアーキテクチャにすることで、(データベースが変わっても)影響範囲を狭めたりデプロイしやすくしたり様々な選択肢を残すことができるアーキテクチャだと思っています

つまり、クリーンアーキテクチャは実装の最初は明確に境界を分けるために苦労(コードが増えたり、冗長なコードを書くことになったり)することになりますが、開発の規模が大きくなったり新しいメンバーが途中で join することになってもコードを見れば理解でき、開発速度を落とさずに継続的に開発していくことができるということにつながります

本記事には具体的なコードは出てこないのでクリーンアーキテクチャ本を読んでもあまり理解できなかった方を対象に概念的なことを書いていきます

アーキテクチャとは

アーキテクチャとは、開発の生産性を上げ、運用・保守を楽にできるようにし、デプロイを継続的にしていくことができるようにシステムの構成を形作るものです

例えば、あなたが学生時代に書いたアーキテクチャもへったくれもないクソコードはそのとき限りの開発には使えたかもしれないですが、継続的にしかも他の人がみても開発速度を落とさずに進めていくことができるでしょうか??

できませんね。

もちろん、設計をしっかりしている人もいるでしょう

ですが、多くの初心者プログラマにとってアーキテクチャとは難解で理解しにくいものです

ここで、一つ問いをしてみたいと思います

アーキテクチャがよければシステムがうまく動き問題なくサービスを受けることができるでしょうか。

いかがでしょうか、一見それっぽい文章に見えますね

答えは、アーキテクチャとシステムの振る舞いは関係がないです。

なぜなら、世の中にはアーキテクチャがしっかり組まれていなくても普通に動いている(ようにみえる)サービスは存在するからです

それこそ、学生時代に書いたコードはそうじゃなかったですか??

私はそうでした。読み返すたびになんてコードを書いてしまったのかと自問自答したものです。

それはさておき、小規模な開発で、短期間という見通しのついている体制ならば適当なアーキテクチャでそのまま開発を続けてもいいでしょう。

アーキテクチャの目的は開発・運用・保守・デプロイへのコストと生産性を高めるためのものだからです。アーキテクチャの良さがわかるのは開発初期ではなくて、数年運用して規模も変わった時にようやくわかる事になるでしょう。

では具体的に開発・運用・保守・デプロイについて考えてみましょう

開発

  • 開発に対するアーキテクチャの目的

開発の規模が大きくなっても、コンポーネントが分かれても開発の速度を落とさないこと

運用

  • 運用に対するアーキテクチャの目的

コストを抑え、また、開発者が見れば運用方法がわかること

保守

  • 保守に対するアーキテクチャの目的

機能追加やバグ修正における適切な場所を見つけるコストを最小限に抑えること

デプロイ

  • デプロイに対するアーキテクチャの目的

一つのアクションで容易にデプロイできるようにすること

全てを最大に保つことは難しい

基本的に開発はサーバーやストレージなどのハードウェアは人間に比べて安価で、人はとても高価です

そう考えてみると開発・保守は明らかに人に対するコストを払いますが、運用はハードウェアに頼れば解決できることもあります。ストレージを増やしたりサーバーのスペックを上げることで、いまいちなアーキテクチャやコードでも処理速度が出せることでしょう。

お金で解決できる問題(運用の一部分)をアーキテクチャで解決しようとすると、それ以上に開発や保守に対するコストが大きくなることが往往にしてあるでしょう。なぜなら処理速度をロースペックなマシンでも捌く方法を設計すること自体が難しく、またそういった設計ができる一部のスーパーエンジニアに対する給料は高くなるので結果的にお金がかかることもあるでしょう。

こういった理由がありアーキテクチャが全ての目的に対して最適であることを保つことはほぼ不可能ともいえるでしょう。

以前アーキテクチャがなぜ大切なのかを書いた記事もあるので興味があれば是非

https://onemuri.space/note/g39GMRckq

まとめ

  • クリーンアーキテクチャは責任の分離をすることで、設計やコードを出来るだけ独立に保つことで開発の容易さや速度を保つもの
  • 規模が大きくなってもアーキテクチャが優れていると途中からエンジニアが参加しやすい状態を保てて、バグ修正などによる保守作業を容易にしておける
  • 万能な考え方は現時点ではなく、メリットデメリットを選択して設計していくことになる

開発において具体的にどう考えるかという記事を以前書いたので興味がある人は読んでみると良いと思います

https://onemuri.space/note/Y6qmOAYFl

参考

Clean Architecture 達人に学ぶソフトウェアの構造と設計

自己紹介用画像

Riki Akagi

2019年からDeNAで働いています。GCP(CloudSQL・GAE・Cloud Function etc)とGoでAPI開発に勤んでいます。睡眠やエンジニアリングに関することに興味を持って過ごしているのでその情報を皆さんに共有していけたらなと思っています。

自己紹介の詳細