第5部
参考
Clean Architecture 達人に学ぶソフトウェアの構造と設計 | Robert C.Martin, 角 征典, 高木 正弘 |本 | 通販 | Amazon
前回の記事
【ミライトデザイン社内勉強会#28】Clean Architecture 輪読会 「第5部：アーキテクチャ①」 - Qiita
第20章 ビジネスルール
DDD の勉強会の時に出てきたビジネスルールとユースケースのイメージ
- えぇんやない
- DDDとクリーンアーキテクチャはそもそも別物だから分けて考えた方がいいけど
EntityとModelって言い方が違うだけで同じものを指しているのかと思ってたけど、同じものを指してる？
- コンテキストによって、意味が違うよ。
- ○○Modelって具体的に何かを指さないと伝わりづらい。
第21章 叫ぶアーキテクチャ
アーキテクチャの目的はシステムの関心ごとからユースケースを切り離すっていう説明がなんとくしっくりきた
- クリーンアーキテクチャはユースケース推し
最初の頃はフレームワークを使うと他のアーキテクチャと共存できないと思っていた。
-
Laravelを使用するのであれば、ドメインとかユースケースとか使うんじゃなくて、LaravelのMVCでの実装としかできないと
- MVCはクリーンアーキテクチャとかオニオンアーキテクチャと並列に並んでいるアーキテクチャ
- Laravel を使うから MVC ってわけではないっていう話
-
「Rails だ」「Spring だ」ではなく「会計システムだ」「在庫管理だ」と叫ぶ
-
優れたアーキテクチャは、ユースケースを強調し、周辺の関心事 ( FW, DB, etc ) から切り離す
-
そうなっていればテストの実行に FW を用いなくて済むし、Web サーバも DB もいらない
第22章 クリーンアーキテクチャ
図22-2（204p）で外部のデータに依存しないように、 DTO とかに詰め替えるのはイメージ着くけど、内部のデータを外部で使用する時も値を外部で使用する用の DTO とかに詰め替える必要があるの？
- View Model とEntities は役割が違うので、詰め替えないと変更する時の理由が異なるので後で困ることになる
- 内から外に依存したらダメ、だからと言って外から内に依存していいってことじゃない
プレゼンターとコントローラーの違いって？
- httpの時はコントローラーがセットになっているので、一緒と考えがちだけど本来は別。
- ゲームで例えるとコントローラーでユーザーの操作を受け付けて、モニター側で表示（プレゼンテーション）している
- Controllerは操作などを受付て、Presenterは結果を返す
第23章 プレゼンターとHumbleObject
テストが難しい処理（ View や DB 接続など処理）のコードがテスト可能な処理の中に入り込んでしまうとシステム全体でテストが難しくなってしまう。
-
だからテストが難しいオブジェクト（ Humble Object ）とそうではないオブジェクトを分離して全体のテスト容易性をあげよう。
-
または、そういう処理がアーキテクチャの境界では多く見られるよっていう紹介。って認識。
-
テスト可能なというよりはテストしなきゃいけないというニュアンスの方が合ってるかも
-
テストしやすくしたいところとにくいところを分けよう
- テストしづらい方を Humble ( 控えめ ) Object と言う
-
たとえば GUI はテストしづらいが、Humble Object を意識すると取り組みやすい
- 「xx がオンという状態とルール」「オンならラジオがこうなるという見た目」に分離する
-
データベースの手前にも他サービスの手前にもいる
-
境界の周辺でこれを上手に使い、システム全体のテスト容易性を大きくあげよう
この章の言ってることははなんとなく理解できたけど、具体的な実装例のイメージがまだつかめない。例えば、アプリケーション層のUserRepositoryインターフェースに準拠しているインフラ層の具象クラスとして、DbUserRepository とInMemoryRepository を作り、InMemoryRepositoryでテストできるようにしているってのとは違う？
-
書き込むときの Date → String の変換ルールとか、重複判定とか、DbXxxRepo の中にも DB を伴わない処理があるはず
-
そういうところの処理と、insert 処理によるテーブルの操作を分離できるぞ、という話
-
Haskeller 風に言うと、副作用から極力関数を分離しようと言う考え方
-
ImMemoryRepo は DIP とモックの話で、テストしやすくなるのは UseCase とか
-
この章は DbXxxRepo をテストしやすくする話
-
save直前のロジックまでならテストが可能なので、別でモデルを作成してテストができるようにするという認識
第24章 部分的な境界線
- 本格的な境界の分離はコストが高いので、「ある程度」ということもある
- たとえば、独立してデプロイ可能にしておいた上で同一コンポにしてしまう方法
- 完全な分離と同じ予備設計は必要だが、複数コンポの管理はしなくて良い
- 片方が意識しておく形もあり、たとえば Strategy や Facade が用いられる
- Strategy は DIP は取り入れられる
- Facade は DIP すら放棄する
- どちらにせよ安易に破れるので、ルールやレビューと勤勉さが必要である
- 境界をいつどこに作るのか、完全かある程度か、を決めるのがアーキテクチャの役割だ
第25章 レイヤーと境界
アーキテクチャの境界となる箇所は至るところにあるよ、今は必要なくても境界が将来必要になることも考えて実装した方が良いのか、それとも無視して実装してしまっても良いのかを常に考えながら実装しないといけないよって書いてあるという理解をした
-
合ってるんじゃない
-
境界はあらゆるところにあり、それがいつ必要になるかをよく留意する必要がある
-
また完全な分離にはコストがかかる
-
なのでアーキテクトは未来に目を向け予測を行わなければいけない
-
決定は一回限りではなく、常に見張る必要がある
次回