Clean Architecture/Robert C. Martin

アンクル・ボブの「Clean」シリーズ第3弾。「クリーン・アーキテクチャ」については、 ずいぶん前に記事が書かれていて、ググるとそれなりにたくさんの言及があります。

私はこれ、知らなかったです。というか、もしかしたら絵を見たことぐらいはあったのかもしれないですが、この絵を見てもここに何か自分の認識を改めるようなエッセンスがあるかどうかって全然わからないので、特に興味を惹かれなかったんだと思います。

で、この本の結論としては、この記事に出ているこの同心円の図がゴールよってことなんですが、そこに至るまでの道のりが丁寧にきっちり書いてあるので、なんかすごく楽しく、納得もしました。

Clean_architecture_2 そもそもこれが同心円になっている理由なんですが、恐らくは古典的なWebの3層モデルとか、MVCアーキテクチャみたいなものがあったとして、その両端、つまりGUIとDBがいずれも最も外側のレイヤーに来るよというようなイメージから来ているんだと思います。

GUIもDBもI/Oなんだから、それが一番下層であり、上から下への1次元のレイヤー構造で書き表すことももちろんできると思うんですが、わざわざ同心円にしているのはその対比のせいですよね。で、この一番外側GUIやDBが来るのはいいんですが、フレームワークも実装の詳細なんだから、一番外にいるべきだと。むしろ、そうさせないフレームワーク(本書の中では「結婚を迫る」というような言われ方をしますが)はよろしくないと。

それらがぜーんぶ一番外の層に来た上での、上の図のCtrlの中を3つのレイヤーにするぜという話で、じゃあ、そこにアプリケーションがどんなビジネスを体現するかに依らないソフトウエアアーキテクチャとしての3つのレイヤーがあるんですよと言われると、「ほう、それはちょっとすぐには思いつかないっすな」って感じじゃないですか。

で、一番内側はエンティティ。ぱっと考えるとエンティティってデータのことなんで一番内側もデータで、一番外側もデータ。どーすんのって思います。

もちろん、ボブおじさんのいうエンティティは、最も高次元のビジネスルールとそれを体現するデータ構造のことなので、RDBのスキーマ構造とは違うもの。つまり、Railsのようにアプリケーション設計において最も根源的なものとしてのビジネスルールとデータを実装の詳細に過ぎないRDBのスキーマを使って表現してしまうようなアーキテクチャを強いるフレームワークは一番よろしくないものってことになります。

よろしくないとどうなるかというと、変更と保守とデプロイが難しくなるよと。ボブおじさんのいうアーキテクチャの役割は、それらに寄与するため(だけ)なので、逆にRailsはそれと何をトレードオフしたのかって話です。ま、そう言われればそうかな。

というわけで、(本書でももちろん言及されているとおり)このアーキテクチャはコストが高いです。あの同心円ではさっぱりイメージがつかめないと思いますが、本書で示されている典型的なJavaで構築されたWeb+DBシステムの構造はこうなります。

Clean_architecture2_2

かなーりリッチ。

<I>って書かれているのはInterfaceで、なんでこんなにやたら出てくるかと言えば、下位のレイヤーを上位のレイヤーは参照できないから。

例えば、DBアクセスで言えば「こんな構造のオブジェクトにデータ詰めてくれや」とユースケース層がData Access Interfaceを定義し、データアクセスをするコンポーネントがそれを実装して、DBから取ったデータを詰めて返すと。つまり、上位レイヤーをビルドするときに、下位のレイヤーをimportしないよと。そう出来て初めて、下位のレイヤーへの依存がなくなるわけです。

この方法を「依存関係逆転の原則」(DIP)と呼んでいて、この本を通じて、ひたすら何度も出てきます。要するに、DIPのDはDI(依存性注入)のDなわけです。SpringみたいなDIコンテナはお馴染みだし、仕組みも使い方も理解しているつもりですが、私はこのDIPという考え方を理解してはじめて存在意義と、ここでなんで"Dependency"という単語が使われているのか理解しました。はー、なるほどね。

で、とにかくモジュール(ソースファイルの単位ぐらいの意味)レベルでも、コンポーネントレベルでも、アーキテクチャを構成するレイヤーレベルでもDIP、DIP、DIPと何度も何度も出てきます。

そして、考えてみれば今こさえてるシステムでも全然できてないですわ。コントロールレイヤーとビジネスルールを形作るロジックのレイヤーとデータアクセスをするレイヤーとちゃんとレイヤー分割はしているけどDIPはまるっきり出来てないです。

しまいにはボブおじさんは「OOPの存在意義は、ポリモーフィズムを使ってDIPが簡単に実装できることだけだ」ぐらいのことを言い出します。でもまあ確かにコンポーネントを正しく分離するには依存関係がちゃんとしている必要があって、単なるユーティリティクラス以上のものをちゃんと交換可能にするためには、DIPされてないとダメだというのはまったくもってその通りです。

ただ、じゃあ本当にこの通りやるのか、こうならないフレームワークはだめなんかと言えば、それはケース・バイ・ケースってことになります。なんせこのアーキテクチャはコストが高いので。そこでバランスを取って何がベストか見極めるのがアーキテクトの仕事だし、そのベストはアプリケーションのライフステージによって変わるので、アーキテクトは常にコードを書きながら(このレベルで言うならば、コード書かないアーキテクトはあり得ない)、常に見極めていかなきゃならんわけです。

というわけで、ものすごく示唆に富み、なおかつ、読んでいて楽しい(ボブおじさんの昔話もいろいろ聞けるし)本です。そして、特にクラスを分割すべきかどうか、モジュールをどうまとめたら良いのかというレベルの設計方針に悩みを持っている人にお勧め。そのレベルの設計方針が積み上がって、最終的にはクリーン・アーキテクチャへたどり着くことになるからです。

| | Comments (0) | TrackBack (0)
|

スクラム現場ガイド -スクラムを始めてみたけどうまくいかない時に読む本-/Mitch Lacey

すでにテスト駆動開発(TDD)と並んで常識というレベルにまで普及したスクラム。少なくとも、思想的には普及しましたよね。

どのぐらい実践されているのかとか、どのぐらい成功裏にプロジェクトが完了しているのかとかは良くわかりませんけど、2018年にシステム開発のプロジェクトをしようとするならば、まず、スクラムが開発手法として選択肢に上がらないことはないでしょう。

とはいえ、です。私がスクラムマスターの研修を受けて思ったことは、「スクラムがきちんと出来るメンバーがそろったならば、スクラムじゃなくたってプロジェクトは上手くいくだろう」ということでした。それまでの開発手法は前提として、それなりの能力を持った開発者やリーダーが定められたプロセスをきちんと実行できるならば、プロジェクトはうまく進むのだとしていました。そのため、プロジェクトにトラブルが生じたら「何が出来ていないのか」ということがチェックされました。

で、よくよく考えてみるとそのプロセスというのは、「ちゃんとやる」ことがすごく難しいものでした。例えば、「要件はすべて明確にされる必要がある」とか「リスクは網羅的に把握されなくてはならない」とか。で、トラブったら「漏れてた」「網羅性に問題があった」と言われるわけですが、いや、「すべて」とか「網羅」とか、普通に無理でしょう。無理だったわけですよ、後から言うのは何とでも出来るけども。

それがスクラムになると、「プロジェクトを進める上で障害が必ずあります。チームはそれをみんなで解決しなくてはいけません」「チームには必ず改善すべき点があります。毎スプリント何かを改善していくことによりチームは向上します」となる。「○○をしろ」ではなく「ゴールを達成するために何をするのか考えて、ベストのことをやれ」になる。抽象度が一つ上がっていて、そのレベルでどう行動するのかのルールが決められたフレームワークがスクラムなので求められていることは難しいわけ。だから、開発者にとって魅力的なんだけども。

そんなスクラムなので、「こういう場合はどうしたらいいの?」というケースはけっこうあると思います。もちろん、スクラム自体はそれに答えてくれないケースも多いんだけど、そのようなケーススタディについていろいろ書いてあるのが、この本です。物語仕立てのケーススタディを読むのがけっこう楽しい。

こんなケースについて、ヒントが得られます。

  • プロジェクトを進めるのに必要なスキルを持つメンバーが集められなかった
  • まだ何も始めてないのにいつ出来るか報告しろと言われた
  • チームでいちばんのリーダーと、いちばん仕様を把握している人と、最も優秀なプログラマが同一人物なので、3つのロールを兼ねた
  • TDDや継続的デリバリーやペアプログラミングはスクラムのプラクティスではないのでやらない
  • 毎日デイリースクラムに遅刻する奴がいて、メンバーがキレた
  • 4週間のスプリントでスプリントバックログを消化しきれないので、5週間に伸ばしたい
  • チームの状態が悪く仕事が終わらないから、レトロスペクティヴをパスしたい
  • チームのスタープレイヤーが異動になった。それも、今日。
  • オフショア先の開発者をチームに入れろと言われた
  • プロジェクトをはじめたいが、プロダクトバックログが数百あって、スプリント1でどれをやればいいか決められない

まあ、あるあるっすなー。

というわけで、スクラムをやり始めたら直面するであろうあるあるについていろいろと検討している本です。具体的な手法や、思考のツールも満載ですし、ケーススタディを通じて「スクラムっぽい考え方」を理解できるというのも良い。語り口も軽やかで読みやすいです。良書ですねー。

| | Comments (0) | TrackBack (0)
|

«F1.2グランプリ 2018前半戦