How to model external API Calls (question from the community)
Martin Dilger
Educating event-driven developers, Building event-sourced Software-Teams | Eventsourcing mit Axon, Spring Boot und Java / Kotlin | Autor "Understanding Eventsourcing" | info@nebulit.de
( this article was Issue #3 on the eventsourcing newsletter - subscribe to get a weekly update like this )
Before you dive into this topic - there is a new Online Course "Implementing Eventsourcing", that will guide you step by step through this process. Find more details at the end of this article.
This was a busy week, wasn′t it?
Not sure where all the time went. This newsletter will be a short one, and I want to pick up a question from the community.
Question is essentially, how do you integrate third party APIs into the process?
Let′s assume an order submit ( what else, right? )
What if you need to carry out a bunch of checks to really be able to submit the order?
There were some interesting comments from community members.
One suggestion was, to call the external API directly in the Command Handler. But what if you need additional data from this API?
Let′s assume you need to calculate the device finger print based on the clients data. The arrow is red for a reason - it′s not clear where the deviceFingerPrint magically comes from.
Then someone brought in processors to the topic. And that′s crucial for me. There is a difference between "fetching" data and mutating external data.
I personally want this to be as transparent as possible. Whenever someone says "third party" - it′s a processor for me. No need to think further.
Implementation-wise, this whole cycle can happen in one request and even be synchronous. But in the Event Model - we don′t talk about the implementation, we try to make it as clear as possible how the information flows.
领英推è
In this case - even a business person would understand there is this "thing" that does some additional processing logic.
Ask 3 developers how this is modelled, and you might get 3 slightly different answers. Eventmodeling is flexible. With great power comes great responsibility. You need to define some rules how things are modelled, so you don′t have to rethink again and again "..and how do we model this today?".
What′s your take on this?
My Accelerate-Toolkit is opinionated on the "how" and gives some guidance. Try it out, it′s free in the community version.
What else happened this week?
We had a webinar yesterday, talking about how to build your own code generator. If you missed it, there is this free 10 day e-mail course you can subscribe to - it will guide you step by step through the process.
My book "Understanding Eventsourcing" is still #1 on Leanpub. Now 2 months in a row after the launch ( with a short 2 day break in-between). That′s so exciting.
I learned yesterday, that whenever I release a new version of the book, people lose their notes. I don′t like that at all, so I′m currently reconsidering whether I will put the "Missing chapters" into the original book. Any thoughts?
Adam will contribute a chapter about "modern Eventmodeling" with a few things that have evolved since the original article.
If you buy the book, you′ll get all "missing chapters" automatically.
And of course - follow us in the weekly podcast:
Want to practice your skills in a safe environment?
The Online Course "Implementing Eventsourcing" gives you exactly that. It′s a perfect companion to the Book "Understanding Eventsourcing"!
Everything I know about Event Modeling & Event Sourcing in one course.
???? Software Craftsman | Domain-Driven Design | Event Sourcing | EventStorming | Event Modeling | Kotlin | Java | C# .NET | Ruby | Node.js
2 个月Martin Dilger it’d love to to see your implementation. For me, one of the greatest benefits of Event Modleing is a 1 to 1 translation to implementation - every pattern has an exact meaning in code. But you suggest there is a view on read model, which do not assume any implementation style.
I help Ruby on Rails teams redesign billing systems by using Event Modeling
2 个月The details may not be immediately obvious, but can we assume that this indirectly makes the external API call asynchronous? How do you differentiate between an already-processed order and an unprocessed one? Currently, I am using a boolean value to convey the order's state, such as { status: :completed, :uncompleted }, but I'm not sure if this is the best approach. Thank you for sharing this!