19年前にこの本に出会っていれば人生は大きく変わったのだろうと思う．
プログラミング初学者の頃に必ず「デザインパターンを学べ」ということを言われるけど，デザインパターンが何の役に立つのか，身近にある問題の中でどのパターンを適用すればその問題は解決するのかというアプローチをしてくれる人に出会ったことがなかった．
実装から抽象的側面を切り出して，それらを独立して変更できるようにする
とか言われましても...でもまぁ必要らしいから読むかぁ...で文字列は目で追えるけど内容は脳に入ってこないままに，なんかそういうパターンがあるんだな！わかった（）となっていた．
その時に，コードを書いている時にすんなり書いていてもハマることがあっても一度立ち止まって「視野を広げる」ということを意識して，繰り返し問題の解決策について考えるということをしていれば，自ずとデザインパターン学習への道が開けていたのかもしれない．
原則について学ぶのが遅かったなー...
〇〇設計だとか◯◯アーキテクチャにとらわれることなく，どの原則を最重要と考えて様々な原則に従ってコードを書いていけえば必然的にコードは良く整理されて，◯◯アーキテクチャに近づいていくから．
常に燃料となっているDDDも，その設計について知らなくとも，業務を良く知ってコードに落とし込むということをしっかりとしていれば，DDDに近づいていくのだから，設計にとらわれて，本質を見失わないようにしないといけないなぁ．