CH8 ブレイクスルー

リファクタリングは時として、突如と現れてプロジェクト全体に衝撃を与えるようなブレイクスルーを発生させる
継続的なリファクタリングによって、開発者の視界は明確になり、洞察のブレイクスルーをもたらす可能性を作り出す

ブレイクスルーの話

シンジケートローンを管理する巨大アプリケーションのコアの開発における例
- はじめは、一般的なケースを極めて単純化した
  - 予想外の要求につまずいて、設計がどんどんと入り組んだものに
- やがて、モデルがビジネスにはふさわしくないことがわかった（ブレイクスルー）
- 新しい的確なモデルが出来上がったが、プロジェクトのスケジュールは大幅に遅れており、変更への恐怖に支配されていた
  - PM との対話により、新しい設計での開発を実現
- 結果、販売部門の担当者も、新しいモデルの言葉を使って、顧客に説明するようになり、理解もしてもらいやすくなった（ユビキタスランゲージ）

好機

より深いモデルへのブレイクスルーは、恐怖も伴う
- チャンスも多いが、リスクも大きい

基本への集中

ブレイクスルーを引き起こすことに気を取られてはいけない
ブレイクスルーは、適度なリファクタリングを何度も繰り返した後に起こり得る

新しい洞察の連鎖

深いモデルへ向かう本物のブレイクスルーの後には、さらなるモデリングのブレイクスルーが連鎖する
たいていのプロジェクトは、すでに構築したものの量と大きさに足を取られて身動きが取れなくなり始める

水上_議論したいこと

8章と関係ないけど気になったこと
- Y案件で、ファイルの操作時に排他制御を掛けていることが業務上要求されている。
  なので、ファイル操作entityの生成時の不変条件が「排他制御を掛けていること」になると考えている。
  ただ、Dto -> entity 時に操作するのであれば、ControllerからRepositoryにアクセスしてしまうので、違和感を感じている。
  また、生成を Controller ではなく Service にすると、 Service に dto を渡す必要があるので、Controllerの知識がServiceに漏れてしまう。
  ライフサイクルの生成タイミングが違うから、そもそも排他制御は不変条件ではない？ => 基本、排他制御は集約で実現すると思うので、排他制御をテーブルロック出かけるという発想自体が微妙＜＝COBOL臭

高木_議論したいこと

細かいリファクタリング（技術的）を継続的にやることでドメインに対する知識が高まる　　＝＞　　急にコアドメインモデルの改善に気づく　　　　＝＞　金がかかるが許容されるのか　 => 自分　だったら「いけます」とはいえないかも　

シェアパイの考え方がわからない、コードで表現できない、誰かコードにして欲しいですお願いします