using event store in a soa

EventStoreDB
#1

Hi

In my opinion a big part of soa is that each service encapsulates its internal representation of whatever part of the domain it implements. In an immutable model, such as event sourcing the benefits of doing this seems a little weakened. Why not let other services subscribe to the internal streams? While still only allowing the owner of the streams the right to write. This would eliminate the need to have internal streams and “public streams” created with some event dispatching functionality… Some of the problems with this approach that comes to mind: we might leak internal class names used for serializing the streams, harder to migrate a stream to a new version of a stream…

#2

Hopefully “class names” won’t be an issue if weaker serialization is used.

You touched on the reason to be explicit about the contracts shared with “other teams”. You have to support those going forward. You can’t suddenly say “we don’t need this event any more, we need these three” [without pain].

#3

Good point about the shared contract.

And with that point in mind I can rephrase the question: Should a service thats responsible for writing a public stream always have some internal representation also?

I would say no…

#4

“always” is a big word. ;-]

#5

If you’re willing to live with the coupling or if the team is strong enough to understand what they’re getting into, it may not be necessary to have an “internal representation”…until it is. Implementation detail.

#6

Using ‘always’ makes it alot easier to answer the question my self :wink: