エピローグ
最先端のプロジェクトに従事して、興味深いアイデアとツールを使って実験するのは非常にやりがいのあることだが、そのソフトウェアに生産的な使いみちがなければ、そうした経験も私にとっては空しいものにすぎない。実際、成功したかどうかの真の評価は、ソフトウェアが長期間にわたってどれだけ役立つかで決まる。(結論より)
残念ながら長期にわたって役にたってきたソフトウェアがイコール、複雑なビジネスの問題領域がソースコードに反映され、しなやかな設計で変更が容易なソフトウェアであるわけではないです。
KentBeckもこんなことを言っています。
読むに耐えないコードが大金を稼いでいる場面を何度も見てきた。(実装パターンより)
ただ、長期に渡って役に立つソフトウェアというのは、どこかで必ずビジネスの転換があり、機能が追加されたり、変更されたり、削除されたりします。
そのとき、ビジネスの転換に合わせてスムーズに変更ができるのは、当然しなやかな設計の方でしょう。
なぜなら、変更の動機はビジネスから発生しているからです。
それにも関わらず読むに耐えないコードが、現在でも量産されているのは、どういった理由からでしょうか？
その理由のひとつとして自分が思い浮かぶのは、フレームワークの進化。
たとえば、DatabaseのマッピングにActiveRecordを採用しテーブルと同等のモデルを書けばDBのCRUDまでしてくれて、かつ規約に基づいたモデルを書けばViewとの接続も容易なRubyOnRails。
起動するだけで、CMSが動作し、多少複雑でもプラグインをインストールしたり、Viewをいじればある程度応用が効くWorｄPress。
こういったフレームワークの進化はエンジニアリングの敷居を低くしてくれました(自分もその恩恵を受けた一人)。
一方、複雑なビジネスの領域は現在でも複雑なままです。
そんなアンマッチングの状況が、複雑なビジネスに立ち向かえないソフトウェアを量産してしまったのではないかと思います。
素人にもわかるフレームワークを作成してはならない。(17章より)
とEvansが言っているのはこういうことだと思います。
(さすがに「設計ができるほどには賢くないのなら、ソフトウェア開発を担当させてはならない。」(17章より)というのは厳しいと思いますが・・・)
実際に動く複雑なソフトウェアを、素人が作成できる時代にはなっていない。(結論より)
今でもこれは言えるのではないですかね。RailsもWordPressも敷居は低いが、DBやViewと密結合で、複雑なドメインを反映できるようなモデルを書けるようにはなってはいないです。だから、
複雑なドメインと格闘して、わかりやすいソフトウェア設計にすることは、優秀な技術者にとって刺激的な挑戦なのだ。(結論より)
優れたソフトウェアを作成することが学び考える活動であるという、中核的な事実を見失ってはならない。モデリングには想像力と自己規律が必要である。(結論より)
ということですよね。ドメイン駆動設計を学ぶのはまだまだ第一歩。ここから実際に複雑なドメインに関わって、関わって、関わって、ソースコードにすること。
１冊読み終わりましたが、学びはこれからです。
あっ!後、追加されたパターンがあるので、もう少し"ちょっとずつ読むドメイン駆動設計"は続きます。。。