質問編集履歴
4
補足
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -20,7 +20,11 @@
|
|
|
20
20
|
|
|
21
21
|
|
|
22
22
|
|
|
23
|
-
前提、ビジネスロジックはバック側に持たせるで良いと思うのですが、画面依存させないAPI(リソース単位のAPI)を提供しているとどうしても、フロント側で一
|
|
23
|
+
前提、ビジネスロジックはバック側に持たせるで良いと思うのですが、画面依存させないAPI(リソース単位のAPI)を提供しているとどうしても、フロント側でリソースAの情報の一部と、リソースBの情報の一部をそれぞれ組み合わせて、加工、判断、計算をしないといけないような場面が出てきてしまうと思っています。
|
|
24
|
+
|
|
25
|
+
|
|
26
|
+
|
|
27
|
+
例えば、ログインユーザーのロールがXYZというロールで、かつ、帳票が生成済みの場合であれば、ダウンロードボタンを表示、または、活性化させたいような場合、ユーザーリソースに含まれるロール情報と、帳票情報に含まれるステータスの両方をみて、ダウンロード可能かどうかをフロント側で判断しないといけないと思います。
|
|
24
28
|
|
|
25
29
|
|
|
26
30
|
|
3
補足
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -86,7 +86,7 @@
|
|
|
86
86
|
|
|
87
87
|
### デメリット
|
|
88
88
|
|
|
89
|
-
- フロント側で一部、ビジネスロジックを持つことが発生し得る。（独り言：リソース単位でフロントにレスポンス返すと、フロントでビジネスロジックを本当に持ち得えるのか？その処理はフロント側にあっても別に問題ないような処理だったりしないのか？つまり、ビジネスロジックであるのかどうか？具体例を挙げて、検討した方が良さそう）
|
|
89
|
+
- フロント側で一部、ビジネスロジックを持つことが発生し得る。（独り言：リソース単位でフロントにレスポンス返すと、フロントでビジネスロジックを本当に持ち得えるのか？その処理はフロント側にあっても別に問題ないような処理だったりしないのか？つまり、ビジネスロジックであるのかどうか？ 改めて、ビジネスロジックとは何かの定義と具体例を挙げて、検討した方が良さそう）
|
|
90
90
|
|
|
91
91
|
|
|
92
92
|
|
2
補足
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -28,17 +28,25 @@
|
|
|
28
28
|
|
|
29
29
|
|
|
30
30
|
|
|
31
|
+
※ EvansのDDD本にあるSmart UIのUIはViewとControllerの両方を含んだプレゼンテーション層を指していると解釈しています。
|
|
32
|
+
|
|
33
|
+
|
|
34
|
+
|
|
31
35
|
以下、メリデリ考えてみました。
|
|
32
36
|
|
|
33
37
|
|
|
34
38
|
|
|
35
39
|
## 画面単位のAPIエンドポイントを用意する場合
|
|
36
40
|
|
|
41
|
+
### 前提
|
|
42
|
+
|
|
43
|
+
画面単位のAPIエンドポイントとは、例えば、このteratailの個別質問詳細ページの場合だと、このページの表示に必要な情報（質問、回答一覧、関連質問一覧など）を１つのエンドポイントがまとめて返してくれるようなものをイメージして言っています。
|
|
44
|
+
|
|
45
|
+
|
|
46
|
+
|
|
37
47
|
### メリット
|
|
38
48
|
|
|
39
|
-
- フロント側は単に表示だけしていれば良く、バック側にビジネスロジックをすべて寄せることができる
|
|
49
|
+
- フロント側は単に表示だけしていれば良く、バック側にビジネスロジックをすべて寄せることができる（あるとしても表示に関するフォーマットのロジックを持つくらい）
|
|
40
|
-
|
|
41
|
-
- あるとしても表示に関するフォーマットのロジックを持つくらい
|
|
42
50
|
|
|
43
51
|
|
|
44
52
|
|
|
@@ -52,9 +60,21 @@
|
|
|
52
60
|
|
|
53
61
|
- ビジネスロジックがバックとフロントの両方に散らばってしまうことになる（フロント側に関しては、フロント側の各画面でビジネスロジックが散らばらないように、store側にビジネスロジックを寄せることで、複数の画面に同じロジックが散らばることは避けられる）
|
|
54
62
|
|
|
63
|
+
- 画面毎に対応する画面用のAPIエンドポイントを用意するので、似たような情報を含んだ情報を返すAPIエンドポイントが増えて気持ち悪い気がする
|
|
64
|
+
|
|
65
|
+
- 画面毎に対応する画面用のAPIエンドポイントを用意するので、APIエンドポイントが増えがち
|
|
66
|
+
|
|
67
|
+
- クライアントがブラウザー、アプリ、CLIと複数ある場合、クライアント毎に表示する情報が異なると思われるので、さらにAPIエンドポイントが増える
|
|
68
|
+
|
|
55
69
|
|
|
56
70
|
|
|
57
71
|
## リソース単位のAPIエンドポイントを用意する場合
|
|
72
|
+
|
|
73
|
+
### 前提
|
|
74
|
+
|
|
75
|
+
リソース単位のAPIエンドポイントとは、例えば、このteratailの個別質問詳細ページの場合だと、このページに対応した質問情報を返すエンドポイントがあったり、回答一覧を返すエンドポイントがあったり、関連した質問情報を返すエンドポイントがそれぞれ存在しているようなものをイメージしています。
|
|
76
|
+
|
|
77
|
+
|
|
58
78
|
|
|
59
79
|
### メリット
|
|
60
80
|
|
|
@@ -66,7 +86,7 @@
|
|
|
66
86
|
|
|
67
87
|
### デメリット
|
|
68
88
|
|
|
69
|
-
- フロント側で一部、ビジネスロジックを持つことが発生し得る。（独り言：リソース単位でフロントにレスポンス返すと、フロントでビジネスロジックを本当に持ち得えるのか？その処理はフロント側にあっても別に問題ないような処理だったりしないのか？具体例を挙げて、検討した方が良さそう）
|
|
89
|
+
- フロント側で一部、ビジネスロジックを持つことが発生し得る。（独り言：リソース単位でフロントにレスポンス返すと、フロントでビジネスロジックを本当に持ち得えるのか？その処理はフロント側にあっても別に問題ないような処理だったりしないのか？つまり、ビジネスロジックであるのかどうか？具体例を挙げて、検討した方が良さそう）
|
|
70
90
|
|
|
71
91
|
|
|
72
92
|
|
|
@@ -84,4 +104,4 @@
|
|
|
84
104
|
|
|
85
105
|
## よくわかっていないけど、BFF ???
|
|
86
106
|
|
|
87
|
-
BFFがあまりなんだかよくわかっていないですが、リソース単位のAPIエンドポイントは用意して、フロントエンド側の個々の画面に必要な情報を返すAPIエンドポイントをBFFに用意する？
|
|
107
|
+
BFFがあまりなんだかよくわかっていないですが、リソース単位のAPIエンドポイントは用意して、フロントエンド側の個々の画面に必要な情報をまとめたレスポンスを返すAPIエンドポイントをBFFに用意する？
|
1
BFF?
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -79,3 +79,9 @@
|
|
|
79
79
|
|
|
80
80
|
|
|
81
81
|
例えば、リソース単位のAPIを叩くのを基本としつつも、そのAPIでは取得出来ない画面固有の差分を取得するAPIエンドポイントを別途用意するみたいなイメージです。
|
|
82
|
+
|
|
83
|
+
|
|
84
|
+
|
|
85
|
+
## よくわかっていないけど、BFF ???
|
|
86
|
+
|
|
87
|
+
BFFがあまりなんだかよくわかっていないですが、リソース単位のAPIエンドポイントは用意して、フロントエンド側の個々の画面に必要な情報を返すAPIエンドポイントをBFFに用意する？
|