ドメイン駆動設計読んだ

ドメイン駆動設計というのはソフトウェア工学のおしゃれな本で，Kindleで買えたので読んだ．ドメインを軸に戦略的に設計しましょうという本．2週間くらいで読めて良い体験できてよかった．

ソフトウェアを，ユーザーインタフェース，アプリケーション，ドメイン，インフラストラクチャという4つの層に分けて，一番重要なのがドメイン層で，ドメイン層にアプリケーションが存在し得る理由がある．銀行システムだったら，口座とか利子みたなやつがドメイン層で，口座がよくできてると銀行としてうまくいく．ATMのタッチパネルというのはユーザーインタフェースで，どんなにATM押しやすくても，ドメイン層に，口座という概念がなくて，ただのハッシュだったりすると，銀行を運営して金を儲けるとか，新たな金融商品とか作るのが困難になる．インフラ層は永続化とかするのだけど，インフラ層がいかによくても，意味ないデータを保存していては銀行倒産する．
アプリケーションの本質的な価値であるコアドメインを継続的に洗練させていき，実装上の用語と，そのドメインを説明する文章の用語を統一させるべきだと述べられている．ユビキタス言語と呼ばれてる．
リファクタリングするにしても，マーティン・ファウラー的なリファクタリングでは，レガシーコード改善というか，技術的な理解しやすさのためにリファクタリングしているけど，この本では，ドメインのより深い理解のためにリファクタリングしていて，自然なモデリングを表現することを目指している．それでよりよい設計が見つかったらユビキタス言語もアップデートして，それで，仕様がだんだんよくなっていく夢のような世界．夢っぽいけど，限界も示されていて，複数のシステムの統合とか，複雑すぎて対処できないので，こういう妥協案があるとか，かなり現実世界的な苦しい感じの例とか出てくる．

ふだん仕事してて，エンジニアはソースコードをgit grepしながら話していて，そうでない人は，企画書かなにか見て話していて，「ここはこう動くはずですよね」「実装はそうなってないようなので直します」とか話してることがある．けっきょく実装がそうなってるならそう動くし，コード読める人じゃないとプロジェクトを管理できないのではとか，そういうことを考えていた．誰でも理解できる共通の言語があるというのはよさそうで，唯一の言葉が，仕様を深く捉えているなら，その通りのクラスを設計するのは理に叶ってる．また，その用語を作るのも，技術者だけでやるんじゃなくて，関係者全員で，正しい捉えかたをしようと協力できたら，人によって思い描くものがちがうみたいなこともなくなりそう．

この本を読むまでは，ドメインとか大したことないんでしょみたいなあまり興味ない感じだったけど，500ページ分くらいひたすらドメインの大切さの話をされて，普段触れ合ってるクラスたちへの見方が変わった気がする．これまではMVCのうちどれですかみたいな，HTMLかHTTPに関係なかったらモデル，みたいな感じだったけど(さすがにそんな雑な見方ではなかった気もするけど)，モデルだけ取ってみても，どの層のモデルなのかとか，正しいクラスたちが登場しているかとか，チームにいきなり参加した人が最初に見るべき重要なクラスはどこかとか，そういう重要なクラスがすぐ見つかるようになっているかとか，そういう見方ができるようになった気がする．とはいえ，気がするだけで，こういうモデリング技術がすぐ身に付くとは思えないので，たまに読み返したり，普段のリファクタリングで実践しようとしてみるとか，そういうことをする必要があると思う．本読むのもいいけど，読むだけで技術ゲットできるなら，世の中のソフトウェアどれも最高の状態になってるはずなので，本よりはむしろ，いかに実践するかというのが重要だと思う．けど手当たり次第に実践する前にはまず本読んでほしい．チームメンバー全員この本読んでたら捗りそうだけど，これ読む前にソフトウェア一般的な知識が要る気がする．とはいっても僕はずっと本読んでるわけじゃなくて昼とか夜とかにちまちま読んで読めてるだけなのでみんなレガシーコード改善ガイドとかまずは読んでほしい．毎月変わるような最新技術とか追い掛けるのもいいけど普段オブジェクト指向で書いてるのだから言語を問わず通用するような設計を気にするのは悪くないと思う．