ドメインモデルの考え方による設計
・データとロジックを一体にして業務ロジックを整理する
・三層のそれぞれの関心事と業務ロジックの分離を徹底する
アプリケーション層について
- アプリケーション層には業務ロジックは書かない
データベース設計に関して
データベース設計の原則
- 名前を省略しない
- 適切なデータ型を使う
-
制約をきちんと使う
- not null
- 一意制約性
- 外部キー制約
画面設計の切り分け方に関して
用途を特定した小さな単位に分けた画面を提供することをタスクベースのユーザインターフェースと呼びます。
タスクベースのユーザインターフェースのメリット
- やりたいことだけに特化した画面を用意して、単純なことを単純にできるようにする
- ユーザーが複雑な画面と向き合わなくていい
- 設計しやすい
API設計に関して
APIを進化させる
-
APIを基本/拡張/個別対応にグルーピングする
- コアとなる基本API
- 拡張API
- 個別対応API
- それぞれのグループの間でAPIを移動する
個別のニーズに対応しつつ、ほかの利用者のニーズとも合致したら共通APIに組み込んでいくという進化型のWebAPIは、環境の変化に対応してAPIの価値を高め続けることができます。
開発プロセスに関して
-
分析工程と設計工程を分離しない
- 同じ人がやることで、作業効率アップ
-
分析設計の成果はコードで表現する(自己文書化)
- 実装されたプログラムのクラス名やメソッド名が業務の用語や概念と一致するようになります。
- 開発エンジニアはドメイン知識への理解が必要