Third-party external integrations and domain Part 2

[jriggins]

I read through this as well as the associated blog post, but for some reason, I still don't have a good understanding of how to integrate third party services into the fmodel architecture.

I'm very new to the codebase and actually looking at ways to port the ideas to Python, so perhaps my issue is in translation. However, I've been looking at the Kotlin examples and I feel like it looks pretty straightforward.

My bigger issue might be learning more about what SagaManagers and ActionPublishers are and how to wire them up. I feel like I'm missing docs on that. Are there any extra examples/docs that someone might be able to provide?

Thanks so much for this content. It is very helpful. I think once I figure out where to put the non-pure code, I'll have a decent grasp of what is going on.

[idugalic]

Hi @jriggins ! Thanks for your question.

Fmodel libraries have been ported to:

• Rust
• TypeScript
• Java

Python

Our friends from Holisticon are working on Python version (expect a lot more, very soon!):

• Python

SagaManager

I admit, that docs on this topic can be better. I hope to change that soon.

Till then, check the Kotlin Fmodel docs, by focusing on the EventSourced scenario (in which Saga Manager could be used).

Saga Manager is not useful in the State Stored Scenario. Fmodel is not promoting Event-Driven architecture in the case of StateStored System. The reason for that is that Events are not API in this case. It is not something you will store durably, and it is only fair not to extend and promote the state-stored system into an Event-Driven system, within the Fmodel.

• distributed, orchestrated
• distributed, choreography

Fmodel-kotlin ref guide uses tabs to explain different scenarios. I hope that it is not confusing to people?!

SagaManager is an event handler essentially. Very similar to MaterializedView. The difference is that Saga Manager uses ActionPublisher interface to publish/dispatch command(s) based on the event it received, and does not use ViewStateRepository to denormalize the state on the Query side as MaterializedView would do:

• reacting on event(s) (effect - not Pure)
• using Saga to compute new Commands/Actions (this part is Pure),
• and using Action Publisher to physically send/dispatch these commands to third-party services or other aggregates (effect - not Pure)

Check the example of PaymentSagaManager and how it is registered in the main application class. It is calling the third-party service.

I appreciate your feedback and I will work on the documentation to improve it.
Looking forward to your next question and suggestions for improvements.

Best,
Ivan

[sampengilly]

I'm a bit lost on the case of state-stored systems. You have answered the question in detail here and on the other thread for event-sourced systems and you make the case here that the solutions mentioned (SagaManager) aren't applicable to state-stored systems and shouldn't be applicable to them. But I feel that still leaves an open question as to how third party integrations and side effects should be done in a state-stored system.

The Fmodel library says it supports both approaches, but it's completely unclear from all the documentation I've read how one might set up a state-stored system in which a side-effecting API call (e.g. a fetch of data, or pushing a command to an external system) might be triggered in response to commands/events. Is it expected that in a state-stored system the application should directly observe the changes to the state itself and use that as the trigger for any side-effects?