Java読書会BOF「現場で役立つシステム設計の原則」を読む会 第2回¶
| 日時 | 2018年9月29日 10:00 - 17:00 |
| 場所 | 川崎市教育文化会館 第3会議室 |
| 出席者(敬称略) | 遠藤、加藤、山田、平山、井上、本間、藪下、常念、高橋(徹) |
第4章 ドメインモデルの考え方で設計する¶
ドメインモデルの考え方を理解する¶
なぜドメインモデルだと複雑な業務ロジックを整理しやすいか¶
本日は、p.102から読書開始です。
(疑問)複雑な計算がある場合、業務データのクラスに入れるのはどうか？
(出席者経験)ホテル予約業務でホテル料金を計算する場合、1つの部屋に泊まる人数が増えると1人あたりの料金が安くなる。また、子供料金は、子供をいったん大人として泊まる人数に勘定して大人1人の料金を計算し、その大人料金の70%として計算する、といった複雑な計算がある。
→ 計算は別クラスとしたい。
クラスに何でもメソッドを詰め込むと複雑になるのではないか？
(出席者経験)IntelliJ ではロジックをがんがん書いていると、invokerクラスを作る推奨を提示し、内部クラスで自動生成する。コンストラクタに引数を入れて計算メソッドを呼ぶと答えを出すもの。
ドメインモデルをどうやって作っていくか¶
部分を作りながら全体を組み立てていく¶
- p.105 「オブジェクト指向のアプローチ」ではボトムアップのアプローチでありトップダウンのアプローチはうまくいかないと著者主張が述べられている。これは極論過ぎるのでは？
- 次のページで「もちろん全体を意識して開発します」と述べているので全否定ではない。
- 第１回で読んだp.101に、データモデルとドメインモデルのクラス図の対比がある。
- (意見)データモデルの図4-1は表記はUMLだが実質ほとんどER図で、クラスはデータに過ぎない。クラスには、属性のみ定義され、操作が無(つまりER図のUMLへの焼き直し)
- (意見)ドメインモデルの図4-2は操作がある。ただし多重度ないのは痛い。
全体と部分を行ったり来たりしながら作っていく¶
- p.107 パッケージ図
- (経験)循環参照を避けるにパッケージ図を書いている
- ここで対象とするパッケージ図はドメインモデル内のみと思われる(フレームワークやデータベース層は対象外)
- (意見)この図4-3の内容ならば、パッケージではなくクラス(初期導出クラス)で関係を記述し、引き続く設計でクラスを追加・削除していき、ある程度クラスが増えた段階でパッケージに纏めていく
- (疑問)時間順の依存だけでよいのか？
- 業務フロー図
- 図4-4は、UMLのアクティビティ図とほぼ一緒と思われる
- (疑問)「出荷を指示する」は必要か？ 「在庫を確認する」から直接「出荷する」に線を結んでもいいのでは？
- (疑問)「指示する」「報告する」と言葉が違うのはなにか？
- 上から下へは「指示」、下から上へは「報告」と使い分けているのかもしれない
- 部門の上下関係を暗喩？
重要な部分から作っていく¶
独立した部品を組み合わせて機能を実現する¶
- (疑問)ドメインクラスはPOJOで記述できるか ?
- p.90 の図を見ると、ドメインクラスはPOJOにできそうだ
- アノテーションはPOJOと言える？ コンパイル時に他のライブラリが必要になるのはどうかな？
ドメインオブジェクトを機能の一部として設計しない¶
- (経験)ロジックの重複が生じたので機能から共通ライブラリへロジックを切り出すと、
機能のコンテクストに依存したロジックになってしまい、重複したコードを切り出して作成する共通化の方法ではコンテクストが合わない等クソライブラリになりがち。
- ドメインから抽出されることが大事。
ドメインオブジェクトの見つけ方¶
重要な関心事や関係性に注目する¶
- (疑問)「関心事」の読み方は、「かんしんじ」、「かんしんごと」どっち？
- 著者が何かのセッションで「かんしんごと」と言っていたらしいので、そちらで読み進める
業務の関心事を分類してみる¶
コトに注目すると全体の関係を整理しやすい¶
コトは業務ルールの宝庫¶
何でも約束してよいわけではない¶
- (疑問) 図4-5 数量パッケージに「販売可能数量」があるのはどうなのか？ 数量とは別なパッケージになるのでは？
期待されるコト、期待されていないコト¶
- (感想)図4-6 予定、実績、差異とクラスを分けたことで、コンテクスト依存が少なくできており、よいと思われる
- (疑問)図4-6 差異から予定と実績への関連線は実線だが、p.118の図4-5で販売可能数量と数量の関係は点線、ここは点線でもいいのでは？
- 設計意図を表現していることを良しとして、ここでは正しいかどうか議論せず、後にレビューするのでよいかと。
業務ルールの記述 〜手続き型とオブジェクト指向の違い¶
業務の関心事の基本パターンを覚えておく¶
ドメインモデルで開発してもトランザクションスクリプトになりがち¶
業務ルールを記述するドメインオブジェクトの基本パターン¶
(疑問)p.125 表の関心事のパターン4つの出所は？
- Evans本には出てない模様
図4-7 口座のクラス図で、現在の在庫数は？
- 入荷履歴と出荷履歴から計算するのではないか
同図 在庫がなくても今後入荷する予定があれば出荷可能としている
ドメインオブジェクトの設計を段階的に改善する¶
組み合わせて確認しながら改良する¶
- 住所クラスで大紛糾
- 都道府県のフィールドがない
- asTextはデバッグ用にしか使えないのでは？
- 郵便番号は数値とは限らない(例、イギリス)
- 東京23区は市がないが、他の政令指定都市は市と区がある * 昔は「東京市」と言っていた(大昔だよ)
- 住所は非常にやっかいなドメイン
- ホテル予約では、宿泊者と予約者が異なることがある。また、会社の住所もあるので、住所だらけになる
- ドメインクラスはしっかりJavadocを書くようにしたい
業務の言葉をコードと一致させると変更が楽になる¶
- クラス名において、業務の用語を英語にしずらい場合、日本語としたい。 しかし、ファイルシステムのエンコーディングの制約があり難しい(UTF-8であっても正規化の違い〜NFDとNFC〜がある等)。
業務を学びながらドメインモデルを成長させていく¶
5章 アプリケーション機能を組み立てる¶
ドメインオブジェクトを使って機能を実現する¶
アプリケーション層のクラスの役割¶
- 図5-1は、p.90の図と違い、画面(プレゼンテーション層)と記録と通知のしくみ(データソース層)から業務ロジック(ドメインモデル)への参照がない
- 主要な繋りだけ表現しているのでは？
- アプリケーション層から1方向でドメインモデルを参照しているのがミソ
三層+ドメインモデルの構造をわかりやすく実装する¶
- p.152 リスト このSpringFrameworkのサービスは書き方が古い。今は@Autowiredは使わずコンストラクタ・インジェクションによる。
@Service
class OrderRegisterService {
private final OrderRepository repository;
OrderRegisterService(OrderRepository repository) {
this.repository = repository;
}
void register(Order order) {
repository.register(order);
}
}
- Springの開発が早くて付いていくのが大変
サービスクラスの設計はごちゃごちゃしやすい¶
画面の多様な要求を小さく分けて整理する¶
プレゼンテーション層に影響される複雑さ¶
- 画面のプロトタイプについて議論(細部略)
- p.158 「1つの画面で、さまざまなニーズに対応できる画面を作るのが普通でしょう。」
- → えーっ、著者の主張？
- 次の段落を読むと、この文は主張ではなく、導入(否定する命題)と思われる。そうであれば、この文のあと、次の段落の先頭に「しかしながら」と接続詞を補う等が必要では？
小さく分ける¶
- 小さく分けすぎると、それらを構成するのが大変になるが、その問題には触れられていない
- p.160 表 参照系の説明 「生成」とあるが、生成は新規にデータを追加するとも取れるので別な表現がよいのでは？
本日は、p.162 「小さく分けたサービスを組み立てる」項の直前まで
川崎市ふれあいねっと市内団体登録の更新¶
本日、かろうじて団体登録の更新ができました。次回更新は2021年9月となります。 構成員登録でご協力いただきました4名の方、ありがとうございます。