「DDD」の版間の差分
提供: 初心者エンジニアの簡易メモ
(→ドメイン層のモデルパターン) |
(→プロジェクト例) |
||
(同じ利用者による、間の8版が非表示) | |||
行16: | 行16: | ||
*アプリケーション層(service) | *アプリケーション層(service) | ||
*データベース層(repository(dao)) | *データベース層(repository(dao)) | ||
− | *ドメイン層( | + | *ドメイン層(Plain Old Java Object Bean Validationなど):要約一覧クラス、要約クラスなど |
ドメイン層の行数は30~60行 | ドメイン層の行数は30~60行 | ||
行32: | 行32: | ||
*リファクタリング:嫌な匂い(DDD初心者には) | *リファクタリング:嫌な匂い(DDD初心者には) | ||
https://www.amazon.co.jp/%E3%83%AA%E3%83%95%E3%82%A1%E3%82%AF%E3%82%BF%E3%83%AA%E3%83%B3%E3%82%B0%E2%80%95%E6%97%A2%E5%AD%98%E3%81%AE%E3%82%B3%E3%83%BC%E3%83%89%E3%82%92%E5%AE%89%E5%85%A8%E3%81%AB%E6%94%B9%E5%96%84%E3%81%99%E3%82%8B%E2%80%95-OBJECT-TECHNOLOGY-Martin-Fowler/dp/427405019X | https://www.amazon.co.jp/%E3%83%AA%E3%83%95%E3%82%A1%E3%82%AF%E3%82%BF%E3%83%AA%E3%83%B3%E3%82%B0%E2%80%95%E6%97%A2%E5%AD%98%E3%81%AE%E3%82%B3%E3%83%BC%E3%83%89%E3%82%92%E5%AE%89%E5%85%A8%E3%81%AB%E6%94%B9%E5%96%84%E3%81%99%E3%82%8B%E2%80%95-OBJECT-TECHNOLOGY-Martin-Fowler/dp/427405019X | ||
+ | |||
+ | ==参考== | ||
+ | http://www.slideshare.net/masuda220/ss-59756718 | ||
+ | |||
+ | ==Clean Architecture== | ||
+ | ドメイン駆動開発(DDD)やユースケース駆動開発(UCDD)を意識して、ビジネスロジックをUIやFrameworkから引き離し、それぞれの層毎に役割と責任を分離したArchitecture | ||
+ | http://qiita.com/koutalou/items/07a4f9cf51a2d13e4cdc | ||
+ | |||
+ | ==プロジェクト例== | ||
+ | <pre> | ||
+ | Repository:読み書き系やdaoのメソッドをそのまま。 | ||
+ | UseCase:ビジネスロジック | ||
+ | Entity:idを持つ定義、httpのレスポンス時の型などをResultとしておくとか | ||
+ | Dao:tableの操作 | ||
+ | Dto:tableのフィールド定義 | ||
+ | Api: httpのServiceクラスなど | ||
+ | Model:生成系 | ||
+ | </pre> |
2021年1月26日 (火) 12:05時点における最新版
ドメイン駆動設計の講習の要約
目次
ソフトウェア設計について
良い設計とは
- 変更が楽で安全
ドメインロジックとは
問題領域の仕組みや約束事を表現したロジック
エリックエバンスの本
- オブジェクト指向について
- 高凝集・疎結合のコード(クラス・メソッド名なども)は利用者の関心ごとと同じにする
- 重要な用語をチームで共有する
設計モデル
- プレゼンテーション層(controller)
- アプリケーション層(service)
- データベース層(repository(dao))
- ドメイン層(Plain Old Java Object Bean Validationなど):要約一覧クラス、要約クラスなど
ドメイン層の行数は30~60行
ドメイン層のモデルパターン
- 識別オブジェクト:判断ロジック、順序
- 値オブジェクト:日付などの単純なデータ加工
- コレクションオブジェクト:同一データについてのデータ加工
- 区分オブジェクト:男女判断とか、権限周り。(enumを使う)
- howよりwhat:add(-1)ではなくpreviousDay()などとする
おすすめ図書
- 実装パターン
- リファクタリング:嫌な匂い(DDD初心者には)
参考
http://www.slideshare.net/masuda220/ss-59756718
Clean Architecture
ドメイン駆動開発(DDD)やユースケース駆動開発(UCDD)を意識して、ビジネスロジックをUIやFrameworkから引き離し、それぞれの層毎に役割と責任を分離したArchitecture http://qiita.com/koutalou/items/07a4f9cf51a2d13e4cdc
プロジェクト例
Repository:読み書き系やdaoのメソッドをそのまま。 UseCase:ビジネスロジック Entity:idを持つ定義、httpのレスポンス時の型などをResultとしておくとか Dao:tableの操作 Dto:tableのフィールド定義 Api: httpのServiceクラスなど Model:生成系