clean architecture 達人に学ぶソフトウェアの構造と設計 を読んだ
- 思想の話
- xx型プログラムとかは制限を設けているだけ
- してもいいではなく、してはいけない
- OOPの利点(というより特徴)はポリモーフィズム
- classA -> classBの関係
- classBを変更したいだけなのにclassAを意識せざるを得ない
- oopはinterfaceが使える!
- classA -> interface <- classB
- 依存関係を制御できる
- オープン・クローズド
- 修正に対して閉じていて、追加に対して開いている
- コードの共通化の話
- 異なるユースケースで同じ処理がある
- コードを共通化しておくと、Bのユースケースで変更があるとAのユースケースで困ることがある
- コードが同じように見えるだけで、本当に同じかどうかはわからない
- 不安定なモジュール(class)に対する依存をやめる
- インターフェイスを作ってそれに依存する
- classA -> classB(不安定)
- classA -> interface(安定) <- classB(不安定)
- 循環依存しない
- classA -> classB -> classC -> classA とか
- 不要なものには依存しない
- 例 classA -> classB.methodA, classB.methodB
- もしclassAはclassB.methodBを必要としていないならおかしい
- これもinterfaceで解決
- classA -> interface.methodAのみとか
- 修正したいものがまとまっていると良い
- classを変更するときに理由はひとつ
- コンポーネントを変更する理由もひとつ
- 単一責任
- 選択肢を残す、決定を遅らせる
- 方針(ビジネスルール)を決める
- 詳細(DI何使う? DB何使う?)は決めない
- 決定を遅らせられれば色々試せるし情報も得られる
- レイヤー
- 水平レイヤー
- システム的な部分
- DB, UI, ビジネスコード, ....
- 垂直レイヤー
- ユースケース
- 注文追加, 注文削除, 編集, ....
- 水平レイヤーでも分割するが、垂直レイヤーでも分割
- 注文追加のときに削除のコードに影響を与えない
- ユースケース
- アクターで考える
- ユースケースで分割すると重複コード
- 今「偶然」同じなだけ
- まとめる必要は無い
- 重要なものとそれ以外で境界線を引く
- ビジネスルールが最重要
- DB, GUIはムシムシで構築できると「決定」を遅らせられる
- マイクロサービスだとかはアーキテクチャにおいて重要ではない
- サービスとサービスの間に境界線があるわけではない
- ビジネスルールは横断的
- テストがプロダクションコードを硬直化させてはならない
- 1個の修正が1000個のテストを壊したら?
- 誰も修正したがらない
- ハードウェアはすぐに時代遅れになる
- ソフトウェアは長寿命
- ハードウェアに依存する(ファームウェアを書いてしまう)とソフトウェアの寿命も決まる
例えばRailsで、Androidアプリで、ってのを実際的には難しいのではと思いながら読んでいた。
`rails new` して、MVCで書いていて、フレームワークに依存してないはずだから
hanamiにすぐに変えられるか、というとうーんとなる気がする。
Androidアプリのコードを書いてて、ハードウェアに依存しないように書いて、
じゃあこれをiOSアプリで書いてと言われたら、うーんとなる気がする。
今までの経験的に、そもそも詳細(ハードウェア、フレームワーク)は真っ先に決まってしまって、
その上で動くコードを書いていたからか感覚と違っている、ように感じる。
例えばrailsであれば、先に素のrubyで、まぁARくらいは使って書いて、
何のフレームワーク使おうか、railsでhanamiで、っていう気持ちに出来れば良いねという感じかな。
なのでビジネスルールのみをコードに落とし込む訓練をしておくと良いのだろうとは思った。
詳細が決定されるのが早い理由は、実際に動いているところを見せる必要があるからかなと。
プロダクトの初期段階だと、そもそも上位の方針が決まっていないので、
プロトタイプを出しまくって方針を固めるってのがアジャイルだとよくあるケースだと思う。
なのでリプレース期とかにはいい気はする。
別にビジネスルールだけコード化して、詳細は後回しすべきとは言っていないので、
普通に開発してく中にも適用することは可能だと思う。
とか書いてたら
- フレームワークと結婚するな
って言葉があった。
- xx型プログラムとかは制限を設けているだけ
- してもいいではなく、してはいけない
- OOPの利点(というより特徴)はポリモーフィズム
- classA -> classBの関係
- classBを変更したいだけなのにclassAを意識せざるを得ない
- oopはinterfaceが使える!
- classA -> interface <- classB
- 依存関係を制御できる
- オープン・クローズド
- 修正に対して閉じていて、追加に対して開いている
- コードの共通化の話
- 異なるユースケースで同じ処理がある
- コードを共通化しておくと、Bのユースケースで変更があるとAのユースケースで困ることがある
- コードが同じように見えるだけで、本当に同じかどうかはわからない
- 不安定なモジュール(class)に対する依存をやめる
- インターフェイスを作ってそれに依存する
- classA -> classB(不安定)
- classA -> interface(安定) <- classB(不安定)
- 循環依存しない
- classA -> classB -> classC -> classA とか
- 不要なものには依存しない
- 例 classA -> classB.methodA, classB.methodB
- もしclassAはclassB.methodBを必要としていないならおかしい
- これもinterfaceで解決
- classA -> interface.methodAのみとか
- 修正したいものがまとまっていると良い
- classを変更するときに理由はひとつ
- コンポーネントを変更する理由もひとつ
- 単一責任
- 選択肢を残す、決定を遅らせる
- 方針(ビジネスルール)を決める
- 詳細(DI何使う? DB何使う?)は決めない
- 決定を遅らせられれば色々試せるし情報も得られる
- レイヤー
- 水平レイヤー
- システム的な部分
- DB, UI, ビジネスコード, ....
- 垂直レイヤー
- ユースケース
- 注文追加, 注文削除, 編集, ....
- 水平レイヤーでも分割するが、垂直レイヤーでも分割
- 注文追加のときに削除のコードに影響を与えない
- ユースケース
- アクターで考える
- ユースケースで分割すると重複コード
- 今「偶然」同じなだけ
- まとめる必要は無い
- 重要なものとそれ以外で境界線を引く
- ビジネスルールが最重要
- DB, GUIはムシムシで構築できると「決定」を遅らせられる
- マイクロサービスだとかはアーキテクチャにおいて重要ではない
- サービスとサービスの間に境界線があるわけではない
- ビジネスルールは横断的
- テストがプロダクションコードを硬直化させてはならない
- 1個の修正が1000個のテストを壊したら?
- 誰も修正したがらない
- ハードウェアはすぐに時代遅れになる
- ソフトウェアは長寿命
- ハードウェアに依存する(ファームウェアを書いてしまう)とソフトウェアの寿命も決まる
例えばRailsで、Androidアプリで、ってのを実際的には難しいのではと思いながら読んでいた。
`rails new` して、MVCで書いていて、フレームワークに依存してないはずだから
hanamiにすぐに変えられるか、というとうーんとなる気がする。
Androidアプリのコードを書いてて、ハードウェアに依存しないように書いて、
じゃあこれをiOSアプリで書いてと言われたら、うーんとなる気がする。
今までの経験的に、そもそも詳細(ハードウェア、フレームワーク)は真っ先に決まってしまって、
その上で動くコードを書いていたからか感覚と違っている、ように感じる。
例えばrailsであれば、先に素のrubyで、まぁARくらいは使って書いて、
何のフレームワーク使おうか、railsでhanamiで、っていう気持ちに出来れば良いねという感じかな。
なのでビジネスルールのみをコードに落とし込む訓練をしておくと良いのだろうとは思った。
詳細が決定されるのが早い理由は、実際に動いているところを見せる必要があるからかなと。
プロダクトの初期段階だと、そもそも上位の方針が決まっていないので、
プロトタイプを出しまくって方針を固めるってのがアジャイルだとよくあるケースだと思う。
なのでリプレース期とかにはいい気はする。
別にビジネスルールだけコード化して、詳細は後回しすべきとは言っていないので、
普通に開発してく中にも適用することは可能だと思う。
とか書いてたら
- フレームワークと結婚するな
って言葉があった。
