😀
業務の関心ごとの基本パターンを覚える
現場で役立つシステム設計を読んだので覚えておきたいことをメモしました。
ドメインモデルで開発してもトランザクションスクリプトになりがち
オブジェクト指向で業務ロジックを整理していても、外部のイベントに応答する入り口になるアプリケーション層のクラスにはif文を使った業務的な判断ロジックが増えがち。
アプリケーション層のクラスに「ちょっとしたif文」を書く方が、ドメインオブジェクトを追加したり、修正するよりも手っ取り早いことが少なくない。
しかし、この「ちょっとしたif文」の追加は、変更を楽に安全にするには、間違った方向、
どこに書くのかを簡単に判断できなかったロジックが、じわじわとアプリケーション層のクラスに増殖していき、次第にif文が複雑化し、異なるクラスに業務ロジックを書いたコードの重複が起きる。結局アプリケーション層のクラスが手続き型のトランザクションスクリプトになってしまう。
このようにトランザクションスクリプトに陥らないためにどのようなことに気をつければ良いか。
業務ルールを記述するドメインオブジェクトの基本パターン
ドメインオブジェクトの設計パターンを体で覚えてしまうのが良い。
まず、下記４つの設計パターンを理解し、実際に書きながら慣れると効果的。
| ドメインオブジェクト | 設計パターン |
|---|---|
| 値オブジェクト | 数値、日付、文字列をラッピングしてロジックを整理する |
| コレクションオブジェクト | 配列やコレクションをラッピングしてロジックを整理する |
| 区分オブジェクト | 区分の定義と区分ごとのロジックを整理する |
| 列挙型の集合操作 | 状態遷移ルールなどを列挙型の集合として整理する |
この４種類のドメインオブジェクトを組み合わせて、次の４つの関心ごとのパターンに業務ロジックを分類して整理していくと、業務ロジックの大半が、アプリケーション層ではなく、ドメインモデルに自然に集まるようになる。
| 関心事のパターン | 業務ロジックの内容 |
|---|---|
| 口座(Account)パターン | 現在の値（現在高）を表現し、妥当性を管理する |
| 期日(DueDate)パターン | 約束の期日と判断を表現する |
| 方針(Policy)パターン | さまざまなルールが複合する、複雑な業務ロジックを表現する |
| 状態(State)パターン | 状態と、状態位遷移のできる/できないを表現する |
以下記事に続く
Discussion