Yabu.log

ITなどの雑記

Java読書会「現場で役立つシステム設計の原則」を読む会 第2回に参加

遅れて午後から参加しました。今回は、書かれていることは確かに理想だけど...という切り口の議論が多かったように思います

かんしんごと vs かんしんじ?

YutakaKatoさんと漢字の読みで張り合っています

www.youtube.com

私は著者が講演で「かんしんごと」と発音しているビデオ(1:28:2~)に影響を受け、これにつられて「かんしんごと」で通しています

なぜ「関心事」だけ「じ」と読むのでしょうか?

「心配事」はいわば和語扱い、「関心事」は漢語扱いだからです。

oshiete.goo.ne.jp

日本語の読み方的には「かんしんじ」が正しいようです😇。DDD界隈読みということもありえるのでしょうか。

まぁ漢字の読み方とかにこだわっているわけではありませんが、この本やたらと「関心事」という単語が出てくるので、どうしても気になってしまうのです。

なんと252回も!出てきますw

とりあえずDRYみたいなのは有害

  • 共通しているからという理由でまとめてはいけない。ドメインの観点から検討して、本当に共通か? を意識して共通化する必要がある。
  • 通化というのは結果にすぎない。
  • とにかくDRY原則!というのが有害
  • 日時系のAPIは日付概念はものすごく抽象化されているから便利に使える
    • とりあえずなんとなく共通処理をまとめました、だと誰も使わない

https://qiita.com/tag1216/items/91a471b33f383981bfaa

  • ドメインを考えるのはすごく大変。重複クラスをまとめるだけなら脳みそを使わない。

Accountパターンの出どころは?

関心事のパターン 業務ロジックの内容
口座(Account)パターン 現在の値(現在高)を表現し、妥当性を管理する
期日(DueDate)パターン 約束の期日と判断を表現する
方針(Policy)パターン 様々なルールが複合する、複雑な業務ロジックを表現する
状態(State)パターン 状態と、状態遷移のできる/できないを表現する

業務ルールを記述するドメインオブジェクトの基本パターンより抜粋 

ちょっと議論の内容は失念したが、こういうプログラミングのプラクティスは

エンタープライズ アプリケーションアーキテクチャパターン (Object Oriented SELECTION)

エンタープライズ アプリケーションアーキテクチャパターン (Object Oriented SELECTION)

アナリシスパターン―再利用可能なオブジェクトモデル (Object Technology Series)

アナリシスパターン―再利用可能なオブジェクトモデル (Object Technology Series)

  • 作者: マーチンファウラー,Martin Fowler,堀内一,友野晶夫,児玉公信,大脇文雄
  • 出版社/メーカー: ピアソンエデュケーション
  • 発売日: 2002/04
  • メディア: 単行本
  • 購入: 7人 クリック: 89回
  • この商品を含むブログ (70件) を見る

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

などが元になっていたりするらしい。 読書家な人が集まっているので「このパターンは一般的なやつ、このパターンはXXに乗ってるやつだね」という流れになったが、Accountパターンは何が元になっているか?という結論が出なかった。 エリックエバンスの本は手元にあったので一応中を調べてみたが、それらしいものはなかった

  • PoEAAの訳はひどい
    • とても読めたものではないので捨てた

粒度の小さいクラスを大量に作ることの是非

本書では単位や属性のクラスをかなり細かく作成していくが、クラス数が増えるほど依存関係が増えたり複雑になるので、とりあえずクラスを小さくすれば良いというものではない。

個人的に大事なことは責務が混ざらない程度に小さくすることだと思う

他技術的なトピックなど

適当に議論中に出たトピックをまとめます

  • for文でコレクションを確認しているコードはStream APIのAnyMatchなどを使うべき

  • JavaのStringクラスの方がクラス設計としては良いが、結果的にRubyが文字列をただのバイト列として扱っているやり方のほうが結果的に成功している

    • JavaがStringクラスに採用している設計パターンが結果的に良くなかったという趣旨の話があった
  • JSR-305

  • Kotlin最高

    • Springの開発スピードが早い(Kotlinの開発がついていけてないらしい)

次回は「小さく分けたサービスを組み立てる」から