Third-party external integrations and domain

[TwiceII]

Hey! First of all, thanks for a great lib and especially for a great blog -- it's one of the clearest and thorough description of this topic I've ever seen.

My question is - how do we reconcile our pristine, pure FP domain core with real-life requirements of interactions with external/third-party services, sending notifications and other side-effecty things?

I know that usually we move these things to the "outside" circles, but I can't find exact place where to put it in your Fmodel. Should they belong to Application service?

After reading Event Modeling Modelling blog, I stumbled on this:

Our system is going to need to communicate with external services. When the guests in our hotel are paying for their stay when they check out, our system makes a call to a payment processor. We can make the concept of how this occurs with the idea of a “todo list” for some processor in our system. This todo list shows tasks we need to complete. Our processor goes through that list from time to time (could be milliseconds or days) and sends out a command to the external system to process the payment, as an example. The reply from the external system is then translated into an event that we store back in our system. This way we keep the building blocks that we use in our system as something that’s meaningful to us.

Here it seems like call to external system is done directly inside command handler (Decider in FModel?). Should we pass some interface inside Decider and then mock it in our domain tests? Kinda ruins FP goodiness for me.

I'd appreciate if you share how you approach this kind of issues in your practical implementations, thank you in advance!

[idugalic]

Hi Twicell,

The short answer is that Decider, View, and Saga should stay pure / without side effects of any kind.

SagaManager should be responsible for integrating:

• two aggregates
• aggregate and third-party service
• kafka/rabbitMq listener and the aggregate

SagaManager is acting as an anti-corruption layer in this case, translating:

• events of one aggregate into command of the second aggregate
• events of the aggregate into HTTP service calls
• messages/responses from Kafka/RabbitMQ into commands of the aggregate.

In this way, the integration is minimizing the runtime coupling between two systems.
Observe how that response/message from the third-party system is always translated into a Command of your own system.
You never skip that input/command, and let that message/response leak deep into your domain language / SagaManager is acting as an anti-corruption layer.

SagaManager is acting as a translator in the event modeling workshop format.

**I plan to write a blog post on this topic very soon and show you the options you have. **

BTW, you can also override the application layer Aggregate and make it use/compose the third-party service. But, there is a reason we have not promoted that by default in our API, more on that in the blog post...

For example, you can control how you instantiate your object (eg. EventSourcingAggregate)

This is what you have now:

fun <C, S, E> EventSourcingAggregate(
    decider: IDecider<C, S, E>,
    eventRepository: EventRepository<C, E>
): EventSourcingAggregate<C, S, E> =
    object : EventSourcingAggregate<C, S, E>,
        EventRepository<C, E> by eventRepository,
        IDecider<C, S, E> by decider {}

You can create your own interface by extending/composing EventSourcingAggregate and your client interface/behaviour:
MyEventSourcingAggregate<C, S, E>: EventSourcingAggregate<C, S, E>, MyThirdPartyServiceClient

and a factory/constructor function:

fun <C, S, E> MyEventSourcingAggregate(
    decider: IDecider<C, S, E>,
    eventRepository: EventRepository<C, E>,
   myClient: MyThirdPartyServiceClient
): MyEventSourcingAggregate<C, S, E> =
    object : EventSourcingAggregate<C, S, E>,
        EventRepository<C, E> by eventRepository,
        IDecider<C, S, E> by decider,
        MyThirdPartyServiceClient by myClient {}

and compose the handle method (by using my client now.) as you find fit. This is our example

In your case you can choose to use that client now:

fun <C, S, E> MyEventSourcingAggregate<C, S, E>.handle(command: C): Flow<E> {
  
   return command
        .fetchEvents()
        .computeNewEvents(command)
        .save()

   val 3partyResult = callMethodsFrom`MyThirdPartyServiceClient`(...)
}

Best and thanks for your questions!

[idugalic]

I just remembered that Fmodel had ProcessManager modeled two years ago, but we have removed it in favor of Decider(Aggregate) + Saga(SagaManager) = ProcessManager

https://github.com/fraktalio/fmodel/blob/e4f4d5c030fe94a76bc23e46e62eb23f76e8bca8/domain/src/main/kotlin/com/fraktalio/fmodel/domain/Process.kt

[idugalic]

Have a look at this Miro https://miro.com/app/board/o9J_ktrZ1rU=/. These three systems are integrated with stateless Sagas.

[TwiceII]

Thanks again, Ivan! I really appreciate your detailed answers, can't wait for your blog post!

[idugalic]

https://fraktalio.com/blog/integration-of-event-driven-systems.html

[idugalic]

Check the PaymentSagaManager and how it is registered in the main application class