勉強会での内容を気になったポイントに絞ってまとめ、僕の感想や気付きなども書いてみました。今まで僕が参加した回の現場から学ぶモデル駆動設計の勉強会での学びや気付きなどについてまとめ記事を作ってみました。「実践!インテグレーションパターン」(勉強会)で印象に残ったところや気づきなどEIPはシステム間でメッセージを非同期に送信するためのパターンランゲージ(送る側から受け取る側までの一連のパターン)。メリットの1つとして時間的な制約が排除できる点がある。自分はシステム間連携の方式として、API連携、ファイル連携は経験がありましたが、メッセージでしかも非同期で連携は聞いたことがありましたが体験したことがありませんでした。時間的な制約が排除できてシステム間の依存関係が緩く柔軟になるということでした。確かにサブシステムと連携してて非同期でもいいような連携をこの仕組みでやれると、サブシステムに引きずられてメインシステムが動かないとかもなくなるのでいいなぁと思いました。マイクロサービスとの親和性もあり、さらに最近ではクラウドでマネージドで簡単に非同期メッセージがやり取りできるようになってきているので今後は今まで以上の勢いでの導入が予想されるそうです。(今のうちに話を聞けて良かった、、、)話を聞くまでは難しすぎてほぼ理解できないかも、、、と思っていましたが分かりやすく説明頂いたこともあり、勉強会の中でEIPのパターンを色々教えていただきましたが、そこまで複雑なものはなく、すっと頭に入る内容でした。簡単なものは自分でも直ぐかけそうだなという印象です。(多分、求められる要件次第でめちゃくちゃ複雑にはなるのでしょうが、、、)インターネットを通ったメッセージは届かないことがあるということを受け入れる。その上で、それを検知してて運用でリカバリか、お金をかけてプログラムで再送する仕組みを作るかは要件次第。この話は、非同期メッセージに限った話ではなく、僕もいつも顧客や営業たちと議論になる話だなと思って聞いていました。年に1回あるかないかの例外的なパターンに対して数百万円かけてわざわざシステム化するんですか??検知だけして手運用でリカバリで良くないですか。?みたいな、、また、インターネットを通ったメッセージは届かないことがあるということを、2人の将軍の例を上げて分かりやすく解説頂きました。送る側は送れたかどうか応答が来なければ認識できない。受取り側は応答を返すが、それが届いたどうか応答の応答が来なければ認識できない。(応答の応答までやると無限に繰り返される)そんな状況で送信保証をするためには、送る側と受取り側にそれぞれdiskを用意して送った事実と受け取った事実をそれぞれ記録して、本当に送れたらその記録を消すという仕組みが必要になる。いう説明をして頂きました。Scalaのコードも見せていただきましたが、、、途中からふわっとしか付いていけず。EIPの考え方は設計に応用できる。いろんな属性を持った大きなデータを細かく分けて個別に処理してインテグレートしたり・・・この話は、こういう考えを持ちながらいろんな分野の勉強をすべきだと考えさせられました。他のところでその考え方を活していく。他で応用できないか??を常に考えながら勉強する。このような意識を持つことの大切さを学ばせていただきました。僕が印象に残ったのはこの辺りでした。コメントをキャンセルメールアドレスが公開されることはありません。コメントデータの処理方法の詳細はこちらをご覧ください。