やったこと

現場で役立つシステム設計の原則

５章・６章読了

学んだこと

アプリケーション層の役割は進行役

プレゼンテーション層（画面）、データソース層（主にRDB）、ドメインモデルの三者のやり取りを制御する。
アプリケーション層に作成するクラスはごちゃごちゃしやすい。

試してみたい業務ロジックを、ひとまずアプリケーション層に記述する、ということが始まるため
- コードが重複していく原因

業務ロジックは、全部ドメインモデルで表現する。
業務ロジックを、一時的にアプリケーション層で実装する場合は、後で必ずドメインモデルへ移行させること。

ドメインモデルを育てる

業務への理解が進むにつれて、初期に作成したドメインモデルがイマイチに感じる。
最新のニーズを満たすよう、ドメインモデルを継続的に改善していく。
「ドメインモデルを育てる」という認識が大事。

ドメインモデル改善時、いい名前が見つからないときは、ドメイン知識の理解が足りていない可能性が高い。
ドメインエキスパートに相談してみよう。

アプリケーション層が複雑になる原因

大きく、以下の二つ。

プレゼンテーション層（画面）の影響を受ける
データソース層（主にRDB）の影響を受ける

プレゼンテーション層（画面）の影響を受ける

■なぜ複雑に？
画面を通して、利用者から様々な要望が生まれる。

利用者にとって、画面こそが、サービスの具体的な形であるため

これらの要望を「ひとまずアプリケーション層で実装」することを繰り返すことで、アプリケーション層が複雑化する。

■複雑さを軽減するには？
①独立性の高い、小さな部品に分離する

分離した小さな部品を組み合わせて、プレゼンテーション層からやってくる要求に対応する。
特に、登録系と参照系の処理を分離すること。

②シナリオクラスの導入
アプリケーション層を、以下の二つに分離する。

基本サービスを提供する「サービスクラス群」
基本サービスを組み合わせて複合サービスを提供する「シナリオクラス群」

サービスクラス群だけでは、どこに何が書いているのかわかりにくく、見通しが悪い。
シナリオクラスの導入で、シナリオ（≒業務知識）からトップダウンでサービスクラスを追跡できるようになり、見通しが改善される。

キーワードとして、以下を説明されていた。

契約による設計(DbC)
防御的プログラミング

データソース層（主にRDB）の影響を受ける

■なぜ複雑に？
業務要件が複雑になると、insertやselectのタイミングも複雑になる。
そのため、どうしても手続きの羅列になる。
手続きの羅列は、以下につながる。

ロジックの散在
ロジックの重複

■複雑さを軽減するには？

リポジトリパターンを用いて、データベース操作ではなく、業務の関心事単位でメソッドを作成する。

以下をリポジトリ内部に隠ぺいし、サービス側から意識させないようにする。

DBへの操作（SQLなど）
- 業務としては、注文が登録できれば良いわけで、SQLの詳細は気にしたくない
テーブル設計の詳細（複数のテーブルにCRUDするなど）
- 業務としては、注文が登録できれば良いわけで、複数のテーブルにCRUDするルールなんて気にしたくない

コトに注目するデータベース設計

データベースの本質は、事実（≒コト）の記録。
事実（≒コト）の記録を徹底することが基本。

ことを正確に記録するために、 Not null 制約、 unique 制約、外部キー制約を十分に活用すること。

以下の工夫は、ヒトやモノとの関係を正確に記録することに貢献する。

記録のタイミングが異なるデータはテーブルを分ける
記録の変更を禁止する
- 修正したい場合、「赤黒処理」と同等の処理を行う
カラムを追加する場合は、テーブルを追加する

コト中心設計の問題点

ことを正確に記録することを目指したDB設計では、カラム数の少ないテーブルが多数作成される。

現在の状態は、過去の記録を集計することで導出できる。
しかし、現在の状態を参照するたびに集計が走るのでは、性能面で問題がでる。

これを緩和させる手段として、インデックス機能の活用とイベントソーシング設計が挙げられる。

その他の工夫

update よりも delete & insert
「記録（入金記録など」」処理と、「状態（残高など）の更新」処理は独立させるべき
- 言い換えると、状態の更新に失敗したからと言って、記録処理を取り消す必要はない
コトの記録と、集計情報やコトの記録のサブセットの参照を分ける
- イベントソーシングにより集計情報を更新する

イベントソーシングを用いた設計は、修正や拡張の柔軟性を高める。
一方で、非機能要件やシステムの運用面からみると、検討するべき課題が多い。

t0mmy

学習履歴詳細