mizoguche.info

現場で役立つシステム設計の原則を読んだ

技術的な話

ざっくりとした技術的な知見としては、

オブジェクト指向を適切にやる、というあたりはオブジェクト指向エクササイズリーダブルコードに書いてあることを実践していこうという感じ。

ゼロベースで改善する姿勢

プレゼンテーション層で実装するようなことをドメイン層へ移す

class Items {
  items: List<Item>;

  fun found(): String {
    if (items.count() == 0) {
      return "見つかりませんでした"
    }

    return "${items.count()}件見つかりました"
  }
}

このロジックをドメインオブジェクトに書くことは、ビューとモデルの分離の原則に違反しているように感じる人もいるかもしれません。

しかし、変更を楽で安全にすることを重視するなら、一覧の結果を持つItemsクラスに、検索結果に応じたメッセージの出し分けのロジックをもたせたほうが、コードがシンプルになります。…(中略)…画面側にif分の条件分岐で書いてしまうと、すべての箇所を洗い出して変更することが必要になってしまいます。

情報の文字列表現は利用者の関心事そのものです。ドメインオブジェクトに記述することは、むしろ自然です。 「現場で役立つシステム設計の原則」増田亨 P.214

そう言われるとそうかなぁという感じではあるが、すんなり腹落ちはしないなぁという感じである。

「見つかりませんでした」と「N件見つかりました」というif文が散らかってる状況があったとき、たぶん自分なら検討もせずにビューとモデルの分離の原則という固定観念に従ってプレゼンテーション層にユーティリティメソッドを作るだろうなーという感じ。

本書での議論は、

という前提があるっぽくて、たとえばドメイン層から日本語のメッセージを返したりなど国際化は考慮されてないコード例が多いと感じる。ので、そのように前提を共有するケースでない限り安易に真似するのは怪我しそうかなーという気持ちになった。

ただ、メリット・デメリットを比較して、常識や固定観念に反した方がメリットが多く改善につながるという判断ができるということは非常に重要だという気付きを得た。

「このコードはドメイン層にプレゼンテーション層の知識が漏れてる」みたいな固定観念によって、改善が阻害されていたかもしれない。

ドメイン駆動設計

エリック・エヴァンスのドメイン駆動設計が参考文献として挙がっているし、エッセンスとしてもドメイン駆動設計的な考え方が多く出てくるが、本書では「ユビキタス言語」など、エリック・エヴァンスのDDD本に出てくる単語はあまり出てこない。

書籍「ドメイン駆動設計」も正式には「エリック・エヴァンスの」と付くように、DDDはベストプラクティスをまとめた知識体系であり、絶対の正解のあるものではありません

DDD + Clean Architecture + UCDOM Full版 // Speaker Deck

「正しいアジャイル」なんてものはないように、「正しいドメイン駆動設計」なんてものもまた存在しないのだろう。チームの状況や開発するものによって適用すべきプラクティスは違うだろうし。

なので、そのようなプラクティスの中から自分たちのチームに合った最適なものを選んで実践し、より価値あるものをより早くユーザーに届けられるよう、改善していかなければならない。

そうして改善を重ね続けたひとつの結果が本書にまとめられているのだろうなーと思う。

まわせPDCAサイクル

PDCAを回して問題点を特定し、それを改善していくという「当たり前」のことをして本書の知見を得たんだろうなーと感じる。

Asian Automation Alliance 自動化を進める・止めるにあたってのヒント

この実行されないKPTに対するディスりをいまだに強烈に覚えてて、いろんな現場でPDCAを回すという「当たり前」のことは上手いこと回ってないんだろうなーと思う。

しっかりPDCA回していきましょう。