[技術書籍レビュー] 手を動かしてわかる クリーンアーキテクチャ

個人的に仕事で、色々な会社の新規サービスシステム開発（または既存サービスのリファクタリング）を行う事が多い。 その時に最も意識するのがアーキテクチャの部分です。 システムの構造体であるアーキテクチャをしっかりと構築する事で、システム全体の安定性を最初からキープする事が目的です。 でも、もちろんシステムって成長する生き物と同じで、その先に要望やニーズによる機能追加や改変でアーキテクチャが当初の思想から外れてしまうこともありますが、 そうならないためのアーキテクチャについての書籍を読んでみようと思って、手に取ってみました。

この書籍の情報

「ヘキサゴンアーキテクチャ」というこれまで聞いた事がないアーキテクト理論を打ち出してそれに対するJava言語でプログラミング解説している書籍です。

対象読者

Webアプリケーションを構築した経験がある全てのソフトウェア開発者。 未経験者でも、この書籍から学べるとのこと。

Github

https://github.com/thombergs/buckpal 書籍に書かれているコードは全て、Githubに掲載されているそうです。

筆者情報

Tom Hambergs 物事をシンプルに考えることに情熱を持っている人。 複雑さは彼に取ってのクリプトナイト。（笑うところ） オーストラリアのシドニーにある、Atlassian社で働く技術者なのだそう。

この書籍のポイント

保守容易性

エンジニアが最も開発で注意するべき、「保守性」とそれに対する「容易性」について書かれています。 仕事における開発は、時間とコストがトレードオフになるのが通常で、確かにそれに対しての納得感はある。 でも、開発環境の事前構築において、開発にかかる時間を軽減化させることも可能なので、会社によってこれらの計数は大きく違う可能性はありますね。

保守が用意ではないソフトウェアは次の２つのどちらか ・ソフトウェアとしての寿命が尽きかけており、変更はほとんど発生せず、発生したとしても、稀である場合。 ・金銭的に裕福な組織が保有するソフトウェアであり、問題の解決に対してお金を払うことへの抵抗がない場合。

ちょっと乱暴ですが、個人的には他にも、スキル不足によるスパゲコードの集合体になっている状態とか、組織員のモチベーション低下によるとか・・・

データベース中心の設計になってしまう問題

適切な開発を行うのであれば、何よりも先にビジネスロジックから実装するべき。

データベースとビジネスロジックが、ニワトリとタマゴのような書き方をしていますが、決してそうではないと自分は思います。 データベースがクソみたいな作りをしている場合、どんなにいいアーキテクチャを構築しても、保守容易性は低くなることはありますし、 データベースがしっかりしていても、ビジネスロジックがクソな場合は、ユーザビリティだけじゃなく、保守するのも嫌になるケースをこれまで何度もみてきました。 要するに、データベースとビジネスロジックのバランスが取れている事が最低限の条件なんじゃないかと・・・（個人的見解です）

ユースケースが見つけづらくなる問題

アーキテクチャは新たな機能を追加したり、既存の機能を変更したりする箇所がコードベースのどこにあるのかを速やかに把握できる構造になっている事が重要。

片付けが下手くそな人が、自分の散らかった部屋で、毎日何かを探していて、年間に何時間探している時間を費やしているかを考えたら怖くなる事ありませんか？ アーキテクチャもそれと同じで、プログラムコードで関数や命令を探して、どの処理がどのコードに書かれていて、これを変更したらどこに依存関係が存在するかを調べるのに膨大な時間を費やします。 これが容易にできるのであれば、保守性が容易になる事が担保できると言ってもいいかもしれませんね。

単一責任の原則

コンポーネントを変更する理由は、１つだけにすべきである。

変な文章ですが、これは依存関係を極力少なくするという意味のようです。 システム内に複数存在するコンポーネントは、他のコンポーネントに依存してはいけないというのが言いたい事だと理解しました。 多くの技術書籍に、依存関係についての禁止事項や、必要条件などが書かれていますが、この書籍も多分の漏れず、ヘキサゴンアーキテクチャを基準に独自理論のように書かれています。

クリーンなアーキテクチャ

タイトルの見出しになっているこの内容が、この書籍のもっとも言いたい事なのだと思いました。 システムにおいて、それぞれのモジュールやクラス、関数などが、依存関係が少ない事が良いとされていますが、 全く依存関係をなくすことは不可能です。 だってそうしたらシステムとして組み上がらないからです。 では、どういう依存が良いのかと言うと、 この図のように、システムの構造を円形で表したときに、中心に向かって依存をさせていくようにするのが、クリーンなアーキテクチャなのだそうです。 ドメイン層が最も内側で、それに向かって依存していくという構造ですね。 既存のフレームワークなどで構築をするときに、この構造を頭に入れていると、設計をするときに頭が整理しやすいかも。

ヘキサゴンアーキテクチャ

何度も出てくる「ヘキサゴンアーキテクチャ」というのが、以下の図です。 上記の円形システム構造と並行して考える構図として扱われていました。

濃いドメインモデルと、薄いドメインモデル

ドメインモデルには、濃淡があるらしく、 濃いドメインモデルというのは、アプリケーションの核にあるドメインモデル内に可能な限り実装されるモデル。 薄いドメインモデルというのは、エンティティに含まれる状態を保持するフィールドと、設定をするためのsetter/getterメソッドだけとなるモデル。 本書籍では、どちらか一方を使うのではなく、バランスよく使いましょうという、意味のない記述がされていました・・・OMG

ソフトウェア開発における短絡的な実装と、割れ窓理論の類似点

割れ窓理論というのは、車を治安の悪い都市と、治安の良い都市に車を駐車しておいたところ、治安の悪い都市では1日も経たないうちに、車の部品が奪い取られてしまいましたが、 治安の良い都市は1週間以上、そのままの状態が続いたそうです。 次に、窓の割れた車を駐車を駐車したところ、治安の良い都市でも、1日も経たないうちに、車の部品が取られたという実験です。 ちなみに、車の部品を窃盗した中には、法律を尊種するべき住民も含まれていたのだそうです（公務員的な職業のことかな？） この実験からわかることは、「状況において人は罪悪感を抱きにくくなる」という事で、ソフトウェア開発においても、 汚いコードに機能追加を行おうとしようとしたときに、似たようなコードを書いても罪悪感を持たなくなるし、 雑な構造におけるソフトウェアにおいては、雑なファイル管理でも、何も問題を感じなくなるという心理です。 変数名や関数名においても、変なローマ字英字で書かれているシステムからは、良質なビジネスロジックを感じ取ることは難しいですよね？

レビュー

★★★☆☆

良いことを書いているように思えますが、他の書籍と似たような内容で少し残念という気持ちもあり、中間点の評価になりました。 この書籍でしか学べないことは、「ヘキサゴンアーキテクチャ」という構造とその理論ですが、 かなり限定的で、実際にどういう場面で生かせるのかという事が事細かく書かれているわけではないので、読んでいる人が勝手に想像をして自己理解していくというスタイルが、 学習書籍としては少しイタい感じがしました。 あと、この手の書籍はほぼJavaで開設される事が多いのですが、Githubで後悔しているコードをそのまま貼り付けて開設されても、 実行してナンボのプログラム挙動は、まるで意味がわからず、コードのどの点が良いのか悪いのかが書かれておらず回りくどい文章を解読していってようやく理解できるまどろこしさは、 もしかしたら翻訳書籍だからかもしれないと感じましたね。

あとがき

個人的には、アプリケーションアーキテクトの、良い例、悪い例を、図式に表現していて欲しかったな〜と思ったのと同時に、 もしかしたら、世の中的にそういう図を集めた書籍はまだないのではないかとも思われた。 Githubで集めてみても面白いかも・・・ きっと、この書籍、初心者が読むのはかなり厳しいと感じたので、もし購入を迷っている初心者の人がいたら、このブログが参考になると幸いです。