※ 2019年7月27日に追記しました。 この記事の最後に、失敗談の補足を書いた記事へのリンクを追加しました。 システムの一部機能を改修するテーマが現在進行中です。テーマは他の箇所に影響がないくらいに分離できるものです。この大きさが丁度いい。チャンスとばかりにリファクタリングすることにしました。 アプリケーションはそれなりにレイヤー化されています。controllerとserviceとrepositoryがある。よくある３層構造です。何を見直して再設計するのか？それはドメインオブジェクトモデルの構築です。 現状のアプリケーションはビジネスロジックをモデリングしたものとは言えない状態です。自分がやったのだけれど。しかしだからでもあります。なぜこうなったかを振り返り、どのようにできたかを考えます。失敗から学べることもあるはずです。 参照側の層は薄く？本当に？ 開発対象のシステムはある情報の検索

『現場で役立つシステム設計の原則』第2章・第3章の内容は、ロジックをどこに書くかということについてです。 第1章に引き続きテクニカルな内容でアプローチしつつ、第4章・ドメインモデルによる設計への導入になっています。 設計は大事 第3章にある「ロジックをどこに書くのがよいかを適切に判断するのが『設計』です」の文が印象的でした。 ロジックをどこに書くかということは非常に大事なことです。よい設計はどこに何が書かれているかを推測しやすくし、要求に対する変更箇所を限定的にしてくれます。 設計のないプログラムは読むのが大変 現場経験の中で、悪い設計を見てきました。もちろん人ごとではなく、自分もそれに荷担していました。 初期開発から担当して、追加開発と保守で6・7年携わったプロジェクトがあります。このプロジェクトで本当に苦労したのが、既存のプログラムを読み解くことです。 障害やあやしげな動作を確認すると