It's in a certain way a very roundabout way to describe a event based SOA system.
Many of the problems described are problems from SOA systems which are using a number of common anti-patterns for SOA systems.
Also the way this person describes DOA is prone to end up with a monolith in _data_ and a just the logic is not monolithic but might end up accidentally being quite tight coupled. (Through it does have some benefits).
Also even with DOA you can end up with internal state coupling between services if you do it wrong. It's harder
then in some bad designed SOA systems but IMHO roughly as likely as a SOA system communicating with events.
---
- So use events if you do SOA (for inter service communication)!
- Never rely on the internal state of another Service.
- Make sure you don't send events to a specific service, instead "just" send events, then all services interested _in that event_ will receive it. (Make sure to subscribe for events independent of their source not services; E.g. use a appropriate event broker or service mech; Sometimes just broadcasting is fine; Oh and naturally storing the event and making that trigger other services works, too. At which point we are back at DOA )
----
DOA is not bad just IMHO misguiding. If you want to use it look at common problems with event based systems for vectors of potential problems wrt. accidental internal state coupling as many of this will apply to DOA, too (if your system becomes complex enough).
Note that I don't mean all problems caused by combining eventual consistency + high horizontal scaling with event systems. Sadly this is just very often mixed up.
Honestly I'm not sure. I listened to some grate talks on youtube about event sourcing mainly for with a scalability focus but I don't remember by whom they where. Most good articles I read about event sourcing for traceability/replyability where pretty old even when I read them a view years ago. Also many articles I read where pretty messy wrt. what applications of event sourcing help with which problems and have which consequences :=(
Give me a minute I will try to find at least some of the sources, but don't get your hopes up.
I wasn't able to find any other talk I watched back then or any of the stuff I did read, but I then last time I looked into talks and reading material about this was ~2.5 Years ago and while a lot of new software and tooling was done since then the principles didn't change. Try some of the other GOTO; talks about it if you like listening to talks, they tend to be quite good.
This was interesting as far as I remember but not what I was looking for:
Many of the problems described are problems from SOA systems which are using a number of common anti-patterns for SOA systems.
Also the way this person describes DOA is prone to end up with a monolith in _data_ and a just the logic is not monolithic but might end up accidentally being quite tight coupled. (Through it does have some benefits).
Also even with DOA you can end up with internal state coupling between services if you do it wrong. It's harder then in some bad designed SOA systems but IMHO roughly as likely as a SOA system communicating with events.
---
- So use events if you do SOA (for inter service communication)! - Never rely on the internal state of another Service. - Make sure you don't send events to a specific service, instead "just" send events, then all services interested _in that event_ will receive it. (Make sure to subscribe for events independent of their source not services; E.g. use a appropriate event broker or service mech; Sometimes just broadcasting is fine; Oh and naturally storing the event and making that trigger other services works, too. At which point we are back at DOA )
----
DOA is not bad just IMHO misguiding. If you want to use it look at common problems with event based systems for vectors of potential problems wrt. accidental internal state coupling as many of this will apply to DOA, too (if your system becomes complex enough).
Note that I don't mean all problems caused by combining eventual consistency + high horizontal scaling with event systems. Sadly this is just very often mixed up.