残
e.g.
受注残
在庫残
請求残
inputとそれの対になるoutputが非同期に起きるから、その間に滞留しているものを残と呼ぶ感じかmrsekut.icon
すべてのやりとりを同期的に行えるならそもそも残という概念が生じない
自動販売機みたいに、注文と納品が一瞬で終わる感じ
2者の間で業務依頼とその遂行があって、それが非同期的に行われるならそこに残がある
その残に対して残の発生イベントと残の解消イベントを考える
残はqueueみたいな感じ
2者が関連する業務を非同期に取り扱える
プログラムと同じで2者が疎結合になる
ただし、入れた順番で処理するわけではない
残は業務を駆動する
残があるということはそれを解消しないといけないので、何かしらの業務が必要
逆に言えば、残が発生しなければ何もしなくていい
有効在庫残で言えば、常に無限に在庫があればその残は発生しない
/mrsekut-book-4297140101/155 (業務実行者の視点から)
活動と活動の間に置かれたバッファ
残はステータスを持つのだろうか #??
継続残の方で見ると、在庫数などのintの数値をステータスとして保持している様に見える
件別残の方だと、誕生と完了の2値なのでステータスは持たないとみなせることが多そう
理論残と実残の照合
理論残と実残はずれることがあるので定期的に照合が必要
長期的に存在している継続残のほうがズレがち
現在庫残で言えば、システム上の在庫と、倉庫にある物理的なものの在庫とか
件別残はライフサイクルが短期的なことが多いのでズレることは少ない
だが、長期的に存在するものはズレうる
例えば売掛金は件別残だが、短期に解消されるとは限らない
他には、お金周りだと、消費税やや数の計算の誤差で他システムとの間に誤差が生じるかもしれない
継続残
在庫数などのステータスを保持することが多い
過去のeventの積み重ねから数値を計算することもできるが、
その業務が存在してからずっと歴史を重ねるので計算コストがかかるし、
理論残と実残がズレがちなので、eventを積み重ねても嬉しさがないことが多い
照合した際に、実残のスナップショットをステータスとして保持する
件別残
その残に関する残の発生イベントと残の解消イベントを記録することが多い
/mrsekut-book-4297140101/058
具体例をたくさん見ると割とわかってきた
/mrsekut-book-4297140101/受注残の具体例
/mrsekut-book-4297140101/有効在庫残の具体例
/mrsekut-book-4297140101/4章の宅配クリーニングでの具体例