独立性

■所感
前章の無駄時間が長かったので、本を読む気力が著しく低下。最初の段落を読んだだけで、思わずくじけそうになった。今更ユースケースの重要性を説かれましても、って感じ。某プリンタメーカーでとあるラインの業務見える化をさせられた時の悪夢がよみがえった。。

■内容について

ユースケース
きちんとしたアーキテクチャで作られたシステムは、振る舞いを探すという行為は発生しない。なぜなら、ユースケースがしっかりとまとまっているからだ、という内容。だよねー、、、ていうか、要件定義の業務分析レベルでユースケースの洗い出しくらいしてるだろ？と。んで、今どきのフレームワークを使ったプロジェクトだったら、その辺をいい感じにオブジェクト化してるだろ？と。UML作るときの取っ掛かりだろうし。

運用
レスポンスに関する話。クリーンアーキテクチャを進めていくと、ビジネスロジックを守るために、どうしてもUIが外部記憶装置への依存度を下げざるを得ない。というか、なんでもこい、的な作りになってしまう。例えば、DBのレスポンスが遅い！となったら、DBを取り換えちゃえばいいんじゃない？的な。。実にクラウド時代的な考え方だ。
この手の話が出るたびに、「でもなー」と考えてしまう。このスマフォ時代、UIはスマートフォンに任せる、これはありありのありだと思う。でも、DBなどの外部連携も隔絶してしまうのはどうなんだろう？
ついこないだ見かけたのが、リスト内でループしながら外部装置にSelectをかける設計書。これでも性能を落とさないデータプロバイダを持っているDBは確かにある。ただし、それなりにコストがかかる。これを、ちょっと外部記憶装置に意識を向けてやるだけで、もっと安価に同じ性能の設計を書くことも可能だ。自分がマネージメントするのであれば、なるべくクリーンを保ちつつも、できる限りコストがかからない状態でお願いしたくなってしまう。implして振る舞いを譲渡すればいいだろ？っていうのもわかるんだけど、もっと全体的な構成を行うにあたって、考慮しておくべき点があるんじゃない？っていう落とし穴に必ずはまってます。

開発
開発チームがお互いに干渉しないようにコンポーネントを分けようねって話。こんなんだったらいいなーって思う。まぁ現実は難しい。チームごとに作業量が均一になるように機械的に振り分けることがほとんどだから、たいていほかのチームと製造個所が被る。下手をするとクラスが被る。マージしてエラーになるまでがテンプレート。

デプロイ
わけろ、わけろ、とにかく分けろ、っていう話。分かれていればデプロイも簡単だよねって。

選択肢を残しておく
また同じ表題。。前章では大切なことが書いてあったけど、こっちはどうでもいい内容だった。。

レイヤーの切り離し
やっと出てきたレイヤー。クリーンアーキテクチャの胆の部分だけど、つまるところは今までと同じ流れで、外的要因はきちんと分離しようねって話。

ユースケースの切り離し
ビジネスルールも、きちんと分けておこうねって話。それに合わせて、UIやDB（多分テーブルと言いたいんだと思う）も分けておくといいよって書いてあったけど。。確かにほかに影響を及ぼさないかもしれないけど、これはさすがにどうだろうと思う。ちょっと一義的すぎるかな、と。

切り離し方法
特になし。

独立した開発が可能
特になし。。

独立デプロイ可能性
この辺いる？？？

重複
コンポーネントの独立性を考えると、重複するコードや機能が発生するのは仕方がないんじゃないだろうか？そもそも、独立していれば、コードが被っていないのであれば修正時のインパクト外になる。直す個所は倍以上になるかもしれないけれど、その分クリーンになるともいえる。なので、ケースバイケースかな。。

切り離し方法（再び）
あまり中身のない話なので割愛。

文章量に対して中身が薄いと感じる内容だった。
まとめにも書いてあったが、結局は「適切」に進めていくことが大事だ、と総括している。
んなもんわかってるわい、と突っ込んでもいいんじゃないかと思う。