ビジネスロジックは、コードと、データと、改修の歴史の3次元で表現されるものなので、本質的に難しいのです
— magnoliak🍧 (@magnolia_k_) August 11, 2019
次の設計Nightに向けたネタの整理
ドメイン知識から、コードへ
DBの寿命はアプリより長い
ハードウェアの寿命(5年〜7年)に合わせて全面的にシステム更改を行ってアプリケーションがかなり書き換わっても（もしくは全部違うパッケージに入れ替わっても）、それまでのデータは捨てられることなく、移行しつつ使われ続ける。そうすると、今のシステムの要件だけでなく、明示的、または暗黙的に過去のシステムの要件が入り込んでいて、それを階層的に理解しないと「データを理解した」という状況に至らないのではないか。
アプリケーションはアドホックに改修され続ける
コード自体は無くなるかもしれないが、コードが実現していた機能や、たくさんのコードの集合が表現していた「プロジェクト固有の設計原則」「隠れた仕様」みたいなものはずっと残っていく（所謂、現行踏襲）。そのコードだけでなく、あるコードが他のコードへ与えた影響だけは残っていく。
歴史は運用と改修の積み重ね
データは運用されることで積み重なり、機能は改修されることで積み重なる。今あるシステムは、データと、コードと、その改修の歴史の積み重ねという3次元で構成されているので、本質的に理解するのは難しいのではないか？
で、本質的に難しいと考えて、どうすればいいのか？という事を考えていくわけです。
本件について、皆様のコメントを頂けるとうれしいです。
