'Event driven' is used to describe a wide range of application and system architectures so it is important to define some context.

: Event driven distributed systems that use asynchronous exchange of events to deliver business functions.

When integrating with an other system I like to keep the exposed integration surface area as low as possible. What I mean by this is that only the required functions are available to the application and that the API is not directly accessed by the software that I am writing. In short - facade the provided API.

Adding an adapter is arguably

This has several advantages;

There are many ways to integrate systems. The seminal work in this space is Gregor Hope book - enterprise integration patterns.

Ingegrating systems that have completely different architectures requires a mapping layer that addresses these compatibilty issues. Asynchronous event driven systems typically encounter these challenges.

Batch data exchange has been the mainstay of system integration for decades. To be successful event driven systems need a way to work with systems that rely on bulk, infrequent exchanges of data i.e. Batch.

When we exchange data each systems has to reconcile the received data against its current view.

When the two systems have different data representations we need to do more work to reconcile the differences. Simple reconciliation might involve time-stamp for when the data changed or to choose one system as the system of record.

System of record reconciliation becomes more complex when we control the system of record but the system we are integrating with does not honor that decision. If that’s the case then the system of record would need to update the system directly using an API.

Quite often batch data exchanges can be delayed because they rely on everything being in place infrequently. File formats change, data problems occur during preparation, data transfer and availability changes. Typical batch cycles of 24 hours can often end up being days.

Batch data comes in two flavors. Point in time state and logs. State data is typically the systems view at the point the file was generated. Be cautious about using the generation time for time based reconciliation because batch data takes time to prepare.

Log data files are a record of changes since the last file was generated. Log data is very similar to events - a point in time record of state. While attractive (from an event point of view) it is unlikely that event data boundaries between systems will match up. Some time ago working with a change log from an external system the system listed field changes first name, second name, date of birth. Our system had events for name change. This meant that field level changes had to be combined with other field changes or existing state so we could generate appropriate events.

Typical Integration patterns

In this pattern each service that needs to integrate with the external service or system does so independent of the other services. Changes in the service only affect a subset of the interaction. Changes to the integrated service require changes to all the services that are affected.

It is challenging to maintain a complete separation between event driven behavior and the integrated system. Concepts and data items naturally leak out of the API and start to invade the event service data model.