.@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

Self-contained Systems und Frontend-Integration – Teil 1

Self-contained Systems (SCS) stellen einen Ansatz zur Modularisierung von Systemen dar. Sie übernehmen viele gute Ideen des Microservices-Konzepts. Eine wichtiges Element ist die Frontend-Integration...

innoq.com
1
/cc @tillsc @nothing_box
2
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.
1
1
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.
1
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.
1
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.
1
An HTML link to another system introduces almost no coupling at all.
1
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.
1
Replying to @OliverLibutzki @tillsc @nothing_box
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.

Dec 7, 2018 · 10:44 AM UTC

1
Replying to @stilkov @OliverLibutzki @tillsc @nothing_box
The more complex the fragment that’s included and the more expectations it has regarding the environment it’s transcluded into, the higher the coupling.
1
Agreed, btw. when I dealed with microservices for the first time I was so confused why these services are consumed by a single monolithic frontend. @scsarchitecture addresses this and confirms that my first impression was not completely wrong. ;-)