この記事は
Alistair CockburnさんのHexagonal architectureを読んだので、特に印象に残った点を引用しながら書いていきます。
Alistair Cockburnさんは
アジャイルソフトウェア開発宣言を考えたエンジニアの一人です。
読み方はカタカナだとアリスターコーバーンが近いでしょうか。
Crystalという開発手法を考えたり、振り返り手法の一つであるKPTの生みの親とも言われたりしています。
CrystalはXPやScrumほど現在の日本では聞かない印象ですが、Cockburnさんはレジェンダリーなソフトウェア開発者です。
アジャイルソフトウェア開発宣言の起草者の一人であり、Architectureとつく記事を書いているという点で共通点のあるRobert C Martin氏(Clean Architectureの著者)より知名度が低い気がするのは、彼の書いた本の邦訳書が現在は絶版だからかもしれません。
以前輪読会で彼の著作を読んだことがあります。学ぶべきところは多かったかと思います。
Architectureって
昨今、先述のClean Architectureという本は、単にCleanという文句が頭についているだけのソフトウェア開発本のシリーズに過ぎず(Clean Code, Clean Agileなどがあります)、そこで紹介されている同心円の図とその中で使われている文言をそのまま今開発しているディレクトリ構造に当てはめることはとくに意味がないので良くないことであると言われています。
これはその通りらしいので、なんとなくArchitectureとつく記事を読む際には気をつけたいなと思っています。
Hexagonal Architectureの意図は
アプリケーションを、ユーザー、プログラム、自動化テスト、バッチスクリプトなどから均等に動くようにし、最終的なランタイムやデータベースから分離してテストや開発できるようにすること。
とのことです。
実際、データベースから分離されていないアプリケーションをどうテスト可能にするかの対応に苦しんでいたりもするので、この意図が目指すところは正しいのかなと直感的には感じます。
彼がこれを考えた動機は
以下の理由で、ビジネスロジックがUIのコードに侵食してきて、問題を引き起こします。
- まず、システムのロジックの一部が変更頻度の高い見た目の詳細(表示されるボタンの場所、フィールドの大きさ)に依存し十分に自動化テストできない
- 同様の理由で、システムが人の手による操作からバッチシステムに移行することが不可能になる
- 更に同様の理由で、プログラムを他のプログラムから動かすことが不可能になる
これを解決するために、多くの人達はアプリケーションにレイヤーを足します、今回が本当にどんな新しいビジネスロジックもそのレイヤーに乗らないことを誓って。
しかしながら、そのレイヤーに新しいビジネスロジックが侵食してくることを検知する仕組みが無いために数年後彼らはそのレイヤーがビジネスロジックにまみれていて、問題を繰り返していることに気づきます。
中略
同様のことはアプリケーションの「反対側」でも起こります。
アプリケーションのロジックが外部のデータベースやサービスに結びついていて、データベースサーバーが停止してしまったりした場合に、プログラマーは何もできなくなります。
この2つの問題が関連しているかは明らかではないですが、これらの問題には対称性があります。
あるある〜と思いました。非常に。
このような経験は多くのプログラマーがすることではないでしょうか。
毎回「これは一時的な対応だから」「そのうち治すから」などと述べながら同じ問題を繰り返し続けます。
PortとAdapterとHexagon
ユーザー側にせよサーバー側にせよ、問題は設計の不備によって引き起こされます。それはビジネスロジックと外部の存在(entities)との交流のもつれです。
これを解決するために、アプリケーションの「外側」と「内側」の非対称性を利用します。内側に関連するコードは外側に染み出すべきではありません。
Hexagonal Architectureはその別名をPorts and Adptersといいます。
以下は完全な翻訳ではなく私の解釈を含みます。
このようなアプリケーションを外側と内側にわけたとき、内側と外側を結びつけるのがPortsです。
例えば、データを取得する際にその保存してある場所がデータベースであろうとファイルであろうと、アプリケーションの側からはAPIとの会話が変わるべきではありません。そのために、同じPortには複数のAdapterが存在し、それはSQLアダプターだったり、ファイルアダプターだったり、mockデータベースのアダプターだったりします。
また、Cockburnさんは、mockデータベースアダプターを最も重要なものと考えています。
これはやはり、開発やテストにおいてデータベースmockを活用することによって、アプリケーションが具体的なデータベースに依存しないようにできる(したい)からということでしょうか。
ところで、Hexagonという名前になっている理由ですが、6という数字に意味があるわけではないらしいです。portやadapterをこの六角形の図に必要に応じて書き込める余地が残せることに意味があるらしい。
僕としては、Cockburnさんはこの書籍の表紙も宝石だし、自分の考えた開発手法にCrystalと名付けているので、カクカクとしたものが好きなのだと思っています。
Use case
Cockburnさんはユースケースについての書籍を書いているので、この記事にももちろん(？)ユースケースについての記述があります。
Hexagonal architectureパターンはユースケースの記述にも役に立ちます。
ユースケース記述によくある間違いとしては、それぞれのPortの外側の技術的な詳細が含まれてしまうことです。
そういったユースケースは長く読みにくくつまらなくメンテナンス性も悪いです。
Ports and Adaptersアーキテクチャを理解することによって、ユースケースはアプリケーションの境界つまり六角形の内側について書くべきであるということがわかります。
こういったユースケースは短く、読みやすく、メンテナンス性もより高く、長期間の安定性もあります。
Writing Effective Use Casesを読んで、開発においてユースケースを取り入れることを試みていますが、どうしても技術的な詳細を書きたくなってしまいます。
実際に書いてみるとわかりますが、技術的詳細を排して書くのは少し訓練がいることだと思います。少なくとも僕は苦労しているので。しかし、技術的詳細を排して書くのが上手い人のユースケースは確かに読みやすいなと思います。
確かに、Hexagonal ArchitectureとユースケースでCockburnさんの考えていることは一貫性があります。
読んでみて
テストを重視する姿勢、SymetryはKent Beckさんも似たようなことを言っていますし、文中にもRobert C MartinさんやMartin Fowlerさんの名前が出てきたりなど、アジャイル系のメンバーは相互に名前を自分の書籍のなかで出したりしていて影響を与えあっているのだなと感じます。
また、Hexagonal Architectureの文のなかで使われているuse caseは冒頭で紹介した彼の書籍であるWriting Effective Use Casesで紹介されているuse caseと同一のものかと思われます。この書籍と合わせてHexagonal Architectureを読むと面白いかもしれません。
最後に
訳からは省略した箇所、誤読の箇所もあろうかと思いますので、詳細が気になったかたはぜひオリジナルの記事や、Cokcburnさんの他の書籍をご参照ください。
Discussion