.@scsarchitecture I just listened to innoq.com/de/podcast/025-scs… I ask myself why you don't name the replication of data as an alternative to including parts of the other system's UI. It's a good approach to bypass the frontend integration problems, isn't it? /cc @ewolff @stilkov

/cc @tillsc @nothing_box

Yes, that’s a good option, too, if you make sure you know where data is mastered, and we use it often. The downside is that you have to take care of synchronization, something you don’t have to do if you do FE integration. Still, both have their place.

Having bounded contexts which interact using domain events is a good choice as the SCS can pick the data which it is interested in by itself. Having such an architecture lowers the need to use these cumbersome frontend integration strategies.

I don’t find them cumbersome at all in many situations. IMO they’re often the cleaner and simpler option, and often reduce coupling. Sometimes they’re not, no tool works for everything.

Honestly, my conclusion might be motivated by my poor knowldegs (and more important) experience concerning SSI and ESI. I can't comprehend the "reduced coupling" argumentation. Including parts of the other system's UI causes a very close coupling.

An HTML link to another system introduces almost no coupling at all.

Exactly, that's why I think that links are a great (and simple) concept. But transcluding HTML code of other systems into my SCS UI introduces close coupling.

Links are one way of front-end integration. Often, they can be progressively enhanced to transclude a simple fragment view of what it is they’re linking to. Coupling increases, but is still drastically less complex than setting up a backend replication & synchronization approach.