Choreographyについて雑多に書き出して考えてみる

マイクロサービスアーキテクチャを考える基に

Choreography・コレオグラフィー

pub/sub

RabbitMQ? akka?

とりあえずakkaで考えてみる。

理屈

• Publisher(顧客サービス)
• Topic(顧客イベント)

• Subscriber(ロイヤリティポイントサービス、郵送サービス、メールサービス)

• Subscriberはどのイベントの時に呼び出されるべきかをTopicに登録する（購読）

• 顧客サービスがTopicに対してイベントをPublishする（出版）
• イベントが発行されたことをSubscriberが検知する

Note

なんかこのやり方だと、TopicとSubscriber側で両方デプロイしなきゃいけない気がするけど、それはいいのかな？

Publisher, Subscriber

Playframework, finatra等で良さそう

Topic

akka-remote http://kimutansk.hatenablog.com/entry/20140924/1411509232

理屈はわかった、じゃあ実際の作りは？

1. クライアントが顧客サービスに対して、顧客登録のリクエストを送信する
2. 顧客登録のリクエストを受け付けた顧客サービスはTopicに対して顧客登録イベントを出版するためのリクエストを送信する
3. Topicはリクエストを受け付けたら顧客登録イベントを出版する
4. TopicのSubscriberは出版されたイベントを受けて、ロイヤリティポイントサービス、郵送サービス、メールサービスへリクエストを送信する

これでいいのか？？？

Note

メールサービスがロイヤリティポイントサービスの結果の値を必要とする場合には、Topic側でそのような作りにする必要がありそう。

etc

https://www.tothepoint.company/blog/microservices-the-most-occurring-obstacles/ http://microservices.io/patterns/microservices.html http://eventuate.io/exampleapps.html https://www.tothepoint.company/blog/microservices-the-most-occurring-obstacles/ http://pkaczor.blogspot.jp/2015/12/akka-ddd-integrating-eventstore.html

マイクロサービスアーキテクチャ