Pythonによるアーキテクチャパターン

第8章 イベントとメッセージバス イベントとメッセージ・バス

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

ここまで、Django で簡単に解決できる単純な問題に、多くの時間とエネルギーを費やしてきた。 テスト容易性と表現力の向上が、本当にその労力に見合うものなのか、 疑問に思うかもしれない。

しかし実際には、コードベースを混乱させるのは明らかな機能ではなく、その周辺にあるグープなのだ。レポーティング、パーミッション、ワークフローなど、多くのオブジェクトに触れるものだ。

在庫切れで注文を割り当てられない場合、購買チームにアラートを出す。彼らは在庫を買い足して問題を解決する。

最初のバージョンでは、製品オーナーはアラートをEメールで送信すればいいと言っている。

我々のシステムアーキテクチャの多くを占める、ありふれたものをプラグインする必要があるときに、我々のアーキテクチャがどのように持ちこたえるかを見てみよう。

最もシンプルで、最も手っ取り早いことから始め、なぜこのような決断が泥の大玉につながるのかについて話す。

次に、Domain Eventsパターンを使って、のユースケースから副作用を分離する方法と、シンプルなMessage Busパターンを使って、それらのイベントに基づいて振る舞いをトリガーする方法を紹介する。これらのイベントを作成するためのいくつかのオプションと、それらをメッセージバスに渡す方法を紹介し、最後に、図8-1でプレビューしたように、Unit of Workパターン 、この2つをエレガントに接続するためにどのように修正できるかを紹介する。

図8-1. システムを流れるイベント

チップ

この章のコードはGitHubのchapter_08_events_and_message_busブランチにある：

git clone https://github.com/cosmicpython/code.git
cd code
git checkout chapter_08_events_and_message_bus
# or to code along, checkout the previous chapter:
git checkout chapter_07_aggregate

混乱を避ける

だから在庫がなくなったらアラートメールを送る。コア・ドメインとは全く関係のないような新しい要求があると、ウェブ・コントローラーにこれらのものを放り込み始めるのはあまりにも簡単だ。

まず、ウェブ・コントローラーを混乱させないようにしよう

、単発のハックとしては問題ないかもしれない：

エンドポイントで叩くだけだ。何が悪いんだ？(src/allocation/entrypoints/flask_app.py)

@app.route("/allocate", methods=['POST'])
def allocate_endpoint():
    line = model.OrderLine(
        request.json['orderid'],
        request.json['sku'],
        request.json['qty'],
    )
    try:
        uow = unit_of_work ...