アドカレ4日目！3日坊主は避けた。えらい！

2,3年前に読んだ本ですが、設計やDDDのことを学んでいく上でとても良い本だったので紹介です。

内容としては、リーダブルコードとDDDを繋ぐような内容になっており、私もDDD本を読んで「抽象的な話が多くてわかんね」となっていたところから「これってDDD本で書いてたあれじゃん」という感じで読むことができました。

お気に入り箇所

設計の善し悪しは、ソフトウェアを変更する時にはっきりします。

「ただ設計をして、実装をして終わり！」ではなく、自分で設計したコードを継続的に変更してこそ、自分が良い設計をしていたかを気づけるという言葉として受け取りました。

今は、依存関係を小さくする・コードの分散を防ぐは当然として、変更を予測して実装をすることが設計の勘所だなーと感じています。

判断や処理のロジックをメソッドに独立させる

メソッドに独立させることで特定の式に名前をつけることができるようになって、名前重要がより捗らせることができます。

また、インターフェースの定義も行いやすくなり依存性注入もしやすくなります。この辺を「依存性逆転の原則」という言葉を使わずにうまく実装で表現しているのもこの本の好きなところです。

データを持つクラスからデータをgetして、そのデータを使って判断/加工/計算するロジックを書き始めたら、何か変だと考えましょう

データオブジェクトから値を取得することについての言及です。最初はgetして加工でもいいが、今後のそれらの処理をデータオブジェクトに移するなど設計改善をしていくかが、ソフトウェアの変更容易性を大きく左右するとも言われています。

最初のお気に入り箇所でも書きましたが、設計の善し悪しは変更する時にわかるもので、そのための違和感やコードの臭さを感じる1つの要素として実装・変更時には意識してみています。

業務知識を広げるほど、クラス名やメソッド名が業務を表現する用語集として育っていく

ドメインオブジェクトの導入における課題として、命名がとてもあると思っています。マニュアルの読み込みはもちろん、セールスやCSメンバーが製品や使い方の説明で使っている言葉を聞くと「その言葉使うんだ」という驚きがあったりします。

その時に、言葉同士の関係性を意識していくと「言葉は違うけれど同じものだった」ということや逆に「同じ単語だが違う意味を持っていた」と業務ロジックに一歩踏み込み先を見据えた実装がしやすくなります。

逆に、これらの言葉の差を吸収していないと話していた要件が微妙にアンジャッシュしていたということもあるので早いうちから認識を揃えて、部署を超えて同じ言葉を使えるとやりやすいですね。

画面に引きずられた設計はソフトウェアの変更を大変にする

画面ごとに実装をするのではなく共通のドメインは統一して呼び出すというのはよくある話ですが、画面が先に作られることで処理が画面に引きずられるというのもよくあります。

デザイナーがいない現場、デザイナーがいる現場の両方を体験したので改めてデザイナーの偉大さとデザインの持つ強さを感じているところではあります。

デザイナーがいない場合、オブジェクト指向UIなどを学習すると画面の方から改善していけるのでおすすめです。また、本書にも書かれていますが、「そもそも画面とドメインオブジェクトの関係がおかしい」という場合は、設計改善チャンス💡なのでガンガン違和感にアンテナをはりましょう。

かっこうのブログ