質問編集履歴
3
補足
title
CHANGED
File without changes
|
body
CHANGED
@@ -11,7 +11,7 @@
|
|
11
11
|
|
12
12
|
メール送信処理はイベントごとに即送信するのではなく、ある程度通知までタイムラグをもたせて複数イベントを集計して送信するようにしたいです(例えば、15分毎の定期スケジューリングなど)。
|
13
13
|
|
14
|
-
その際に、一つのオブジェクトリソースに対して複数のステータスの変更が加えられた場合、最終的なステートを通知できるような設計を考えています(例えば、タスクで言うと短時間の間に複数回ステータスが変更された場合、全てのステータス変更イベントを列挙するのではなく最終的なステータスを通知する)。
|
14
|
+
その際に、一つのオブジェクトリソースに対して複数のステータスの変更が加えられた場合、最終的なステートを通知できるような設計を考えています(例えば、タスクで言うと短時間の間に複数回ステータスが変更された場合、全てのステータス変更イベントを列挙するのではなく最終的なステータスを通知する。[イベントソーシング](https://docs.microsoft.com/ja-jp/azure/architecture/patterns/event-sourcing)のようなイメージ)。
|
15
15
|
|
16
16
|
上記の要件を踏まえた上で、DB設計・実装方針についてアドバイスを頂きたく思います。
|
17
17
|
|
2
typo
title
CHANGED
File without changes
|
body
CHANGED
@@ -7,7 +7,7 @@
|
|
7
7
|
- あるユーザ(依頼者)が、他のユーザ(担当者)にタスクをアサインした場合に、担当者ユーザにメールで通知が行く
|
8
8
|
- あるタスクにコメントがついた場合、そのタスクの担当者にメールが行く
|
9
9
|
|
10
|
-
などなど。あるについて何らかの変更が加えられた場合、それに関連があるユーザにメール通知が行くといった感じです。
|
10
|
+
などなど。あるオブジェクトリソースについて何らかの変更が加えられた場合、それに関連があるユーザにメール通知が行くといった感じです。
|
11
11
|
|
12
12
|
メール送信処理はイベントごとに即送信するのではなく、ある程度通知までタイムラグをもたせて複数イベントを集計して送信するようにしたいです(例えば、15分毎の定期スケジューリングなど)。
|
13
13
|
|
1
追加の情報
title
CHANGED
File without changes
|
body
CHANGED
@@ -18,4 +18,10 @@
|
|
18
18
|
ちなみにですが、当該サービスの運用は GCP を想定しています(ソリューションとなるマネージドサービスがあるかもしれないので念の為共有)。
|
19
19
|
|
20
20
|
|
21
|
-
何卒よろしくお願い致します。
|
21
|
+
何卒よろしくお願い致します。
|
22
|
+
|
23
|
+
|
24
|
+
---
|
25
|
+
追記:
|
26
|
+
|
27
|
+
[イベントソーシング](https://docs.microsoft.com/ja-jp/azure/architecture/patterns/event-sourcing)などの手法も考えましたが、元々DDDでエンティティの管理に用いる手法だという認識で、自身の経験不足もありまして今回の要件に合うか判断がつかず...ご参考までに。
|