質問編集履歴
5
文言修正
title
CHANGED
|
File without changes
|
body
CHANGED
|
@@ -46,6 +46,7 @@
|
|
|
46
46
|
※1：ここでいう"技術"はWebであればリクエスト/レスポンスのようなもののことであり、仮にビジネスのコアになるような技術ならドメイン層にすることもある。
|
|
47
47
|
|
|
48
48
|
以上から、別にドメイン層の設計を必ずエンティティや値オブジェクトの様に表現しなければならないというわけでもない。
|
|
49
|
-
その為、ドメイン駆動であってもドメイン層がデータ中心なアプローチで手続き的になる事もあり得る。
|
|
49
|
+
その為、ドメイン駆動であってもドメイン層がデータ中心なアプローチで手続き的になる事もあり得る。
|
|
50
|
+
(勿論、データとロジックをカプセル化するオブジェクト指向的なものが、ドメイン駆動の説明にマッチしているとは思いますが...)
|
|
50
51
|
|
|
51
52
|
ちょっと頭が固すぎました^ ^
|
4
文言修正
title
CHANGED
|
File without changes
|
body
CHANGED
|
@@ -35,7 +35,8 @@
|
|
|
35
35
|
(Springにおける開発は、ビジネスロジックに集中するとは言っても、データクラスとロジックのみを扱う@Serviceクラスで分けて表現するという思想？)
|
|
36
36
|
|
|
37
37
|
### 追記
|
|
38
|
+
回答頂いた後も学習を続けた結果、「ドメイン駆動設計」の捉え方が悪かったかもしれないと気づきました。
|
|
38
|
-
|
|
39
|
+
エヴァンス本スタートだったので、同書籍で紹介されているようなエンティティや値オブジェクト等の形を意識しすぎていた。
|
|
39
40
|
現在は、あくまでドメイン駆動の本質は以下の点であるという考え方に変わった。
|
|
40
41
|
|
|
41
42
|
- ドメイン層といったレイヤーを作り、ここにビジネスモデル(ロジック)を閉じ込める
|
3
回答を受けての見解
title
CHANGED
|
File without changes
|
body
CHANGED
|
@@ -32,4 +32,19 @@
|
|
|
32
32
|
Springは開発者をビジネスロジックの開発に集中できるようにするアーキテクチャになっていたと思うので、勝手にドメイン駆動開発に適していると思い込んでいましたが、そもそもこれが誤りでしょうか？
|
|
33
33
|
|
|
34
34
|
つまり、ドメイン駆動開発の様なオブジェクト指向をフル活用しているデータとその振る舞いを表現する様な設計はそもそも想定していないのでしょうか？
|
|
35
|
-
(Springにおける開発は、ビジネスロジックに集中するとは言っても、データクラスとロジックのみを扱う@Serviceクラスで分けて表現するという思想？)
|
|
35
|
+
(Springにおける開発は、ビジネスロジックに集中するとは言っても、データクラスとロジックのみを扱う@Serviceクラスで分けて表現するという思想？)
|
|
36
|
+
|
|
37
|
+
### 追記
|
|
38
|
+
「ドメイン駆動設計」の捉え方が悪かったかもしれない。エヴァンス本スタートだったので、同書籍で紹介されているようなエンティティや値オブジェクト等の形を意識しすぎていた。
|
|
39
|
+
現在は、あくまでドメイン駆動の本質は以下の点であるという考え方に変わった。
|
|
40
|
+
|
|
41
|
+
- ドメイン層といったレイヤーを作り、ここにビジネスモデル(ロジック)を閉じ込める
|
|
42
|
+
- 技術や他システム間(DB、外部API等)のやり取りロジックは、ドメイン層以外の上位層(外側)で吸収する (※1)
|
|
43
|
+
- 各レイヤーの依存方向をドメイン層に向ける
|
|
44
|
+
|
|
45
|
+
※1：ここでいう"技術"はWebであればリクエスト/レスポンスのようなもののことであり、仮にビジネスのコアになるような技術ならドメイン層にすることもある。
|
|
46
|
+
|
|
47
|
+
以上から、別にドメイン層の設計を必ずエンティティや値オブジェクトの様に表現しなければならないというわけでもない。
|
|
48
|
+
その為、ドメイン駆動であってもドメイン層がデータ中心なアプローチで手続き的になる事もあり得る。(色々反論はあるでしょうが...)
|
|
49
|
+
|
|
50
|
+
ちょっと頭が固すぎました^ ^
|
2
質問文言の修正
title
CHANGED
|
File without changes
|
body
CHANGED
|
@@ -29,7 +29,7 @@
|
|
|
29
29
|
※ページ(html)を返却する場合は、比較的簡単かと思います。
|
|
30
30
|
|
|
31
31
|
### 3. そもそもSpringMVCとドメイン駆動の相性が悪い
|
|
32
|
-
Springは開発者を
|
|
32
|
+
Springは開発者をビジネスロジックの開発に集中できるようにするアーキテクチャになっていたと思うので、勝手にドメイン駆動開発に適していると思い込んでいましたが、そもそもこれが誤りでしょうか？
|
|
33
33
|
|
|
34
34
|
つまり、ドメイン駆動開発の様なオブジェクト指向をフル活用しているデータとその振る舞いを表現する様な設計はそもそも想定していないのでしょうか？
|
|
35
|
-
(Springにおける開発はデータクラスと
|
|
35
|
+
(Springにおける開発は、ビジネスロジックに集中するとは言っても、データクラスとロジックのみを扱う@Serviceクラスで分けて表現するという思想？)
|
1
質問の追加
title
CHANGED
|
File without changes
|
body
CHANGED
|
@@ -26,4 +26,10 @@
|
|
|
26
26
|
@JsonPropertyで対応できない事も無いですが、json構造の設計自由度は下がるのでやはりDBと同様に変換用のConvertクラスとDTOが必要になると考えています。
|
|
27
27
|
|
|
28
28
|
- **こちらも同様にドメイン外の実装コストは払うほかないでしょうか？**
|
|
29
|
-
※ページ(html)を返却する場合は、比較的簡単かと思います。
|
|
29
|
+
※ページ(html)を返却する場合は、比較的簡単かと思います。
|
|
30
|
+
|
|
31
|
+
### 3. そもそもSpringMVCとドメイン駆動の相性が悪い
|
|
32
|
+
Springは開発者をドメイン開発に集中できるようにするアーキテクチャになっていたと思うので、勝手にドメイン駆動開発に適していると思い込んでいましたが、そもそもこれが誤りでしょうか？
|
|
33
|
+
|
|
34
|
+
つまり、ドメイン駆動開発の様なオブジェクト指向をフル活用しているデータとその振る舞いを表現する様な設計はそもそも想定していないのでしょうか？
|
|
35
|
+
(Springにおける開発はデータクラスと、ロジックのみを扱う@Serviceクラスでビジネスロジックを表現するという思想？)
|