「注文」から「出荷」への業務プロセス連鎖部位をDDD的に解釈したい！
-
Tanaka9230
- 1654
- 1
- 2
- 0
-
- いいね！0
たなかこういち
@Tanaka9230
一つの業務フローには、アクターは複数人登場し得ます。 例えば、、注文集約であれば、購入者と管理者が登場します。キャンセルに遷移させるアクションは購入者によってトリガーされます。出荷作業中に遷移させるアクションは管理者によってトリガーされます。この二つは競争的です。
2020-03-12 00:57:55
たなかこういち
@Tanaka9230
注文の業務フローは注文集約に実装できます。 注文の業務フローは、出荷の業務フローから区別されるという点で、出荷のとは異なるコンテキストにあると言えます。 注文の業務フローにはアクターが2種類登場するので、そこには(相対的に粒度の小さい)コンテキストが2つ含まれている、とも言えそうです。
2020-03-12 01:01:43
たなかこういち
@Tanaka9230
次に、注文業務フローから出荷業務フローに繋がる部位を考えます。集約をまたぐ=業務フローをまたぐことこそが「業務プロセス」だと(ここでは)定義します。 リンク先の議論から、結論として、プロセスレベル=業務フローまたぎのは、また別の業務領域として認識すべき、です。 togetter.com/li/1480027
2020-03-12 01:10:14
たなかこういち
@Tanaka9230
注文から出荷への連携部位には、「注文そのもの」とも「出荷そのもの」とも異なる、同梱・分納・再送など、固有の業務ルールや手順が厳然と存在します。
2020-03-12 01:13:24
たなかこういち
@Tanaka9230
改めて考えるに、、このようなプロセスレベル=フロー連鎖に関わる業務処理は、基本的に、「ある集約を異なる集約に変換する」というパターンをとります。 一つの集約の状態更新では無いです。
2020-03-12 01:19:49
たなかこういち
@Tanaka9230
じゃっかんイベントソーシングの話っぽいですが、、 方式としては、出荷集約の更新イベントをpublishして、それをsubscriberは読む、でいいですが、そのsubscriberは、やはり「ある集約を異なる集約に変換する」という固有の業務を実装する必要があります。
2020-03-12 01:22:45
たなかこういち
@Tanaka9230
要は、単純にSourceのプロジェクションを取る、という話ではない、ということです。例えば、注文と出荷は、通常n対nの関係になります。
2020-03-12 01:25:41
たなかこういち
@Tanaka9230
「集約を異なる集約に変換する」という、プロセスレベル=フロー連鎖部位の業務処理は、集約に属する処理に落とし込むのは無理っぽいですが、ではApplicationServiceなのか、というと、、これはこれでDomain知識だと言いたい。
2020-03-12 01:33:38
たなかこういち
@Tanaka9230
例えば、注文Actionでは、注文集約を作るだけでなく、決済, 在庫引当, ポイント加減算, 通知メール送信, ...などの処理をします。 注文から出荷への連鎖部位では、注文集約から出荷集約の構築をしますが、 注文Actionのと同じレベルは扱いたくない感じ。
2020-03-12 01:37:53
たなかこういち
@Tanaka9230
で引用ツイあたりの話になります。 twitter.com/iteman/status/…
2020-03-12 01:46:45
Atsuhiro Kubo
@iteman
@sugimoto_kei 「責務のレイヤ」ですね。PHPメンターズの過去の関連記事もあります。 phpmentors.jp/post/820419520…
2020-03-11 13:54:11
たなかこういち
@Tanaka9230
話飛びますが、、 この一連のツイでの用語で言えば、一つの「業務フロー」内であれば、フロントエンド目線だけで(=バックエンド目線なしで)構築しきれると思うんです。 注文と出荷の二つがあるなら、それぞれを個別に作ることはできると思う。
2020-03-12 01:56:48
たなかこういち
@Tanaka9230
※念の為、ここでの「フロントエンド目線」とは、選択する要素技術のことは言っていません。仮にLambdaとDynamoだけで構築するとしても、フロント/バックの目線違いはあるだろう、という話です。
2020-03-12 01:56:48