facebook twitter hatena line email

「DDD」の版間の差分

提供: 初心者エンジニアの簡易メモ
移動: 案内検索
(プロジェクト例)
 
(同じ利用者による、間の7版が非表示)
行16: 行16:
 
*アプリケーション層(service)
 
*アプリケーション層(service)
 
*データベース層(repository(dao))
 
*データベース層(repository(dao))
*ドメイン層(plain,validateなど):要約一覧クラス、要約クラスなど
+
*ドメイン層(Plain Old Java Object Bean Validationなど):要約一覧クラス、要約クラスなど
  
 
ドメイン層の行数は30~60行
 
ドメイン層の行数は30~60行
行35: 行35:
 
==参考==
 
==参考==
 
http://www.slideshare.net/masuda220/ss-59756718
 
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()などとする

おすすめ図書

  • 実装パターン

https://www.amazon.co.jp/%E5%AE%9F%E8%A3%85%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3-%E3%82%B1%E3%83%B3%E3%83%88%E3%83%BB%E3%83%99%E3%83%83%E3%82%AF/dp/4894712873

  • リファクタリング:嫌な匂い(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

参考

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:生成系