Hacker News Reader

I'm guessing the OP meant event driven with persistent events. If the events exist only at runtime then a lot of burden related to schema evolution disappears.

We tried this approach a couple of times with mixed results. In one case, for a new component with strict DDD modeling - it was a boom to productivity. In others , preexisting once we never got to realize the gains, invested quite a bit , not sure if we ever get the upside.

View on HN

You are right, that's what I was referring to.

I have seen DDD working sufficiently well for some use-cases but issues started appearing when the business redefined what the domains are and how the org is structured. I guess there is not a single straight-forward solution to this.

I'm not sure what properties of the system you assign to the DDD label, but in my experience DDD just means you put the domain first. It's all the Event Sourcing and CQRS baggage which gets lumped together with DDD and adds heaps of non-essential complexity.

If the understanding of the domain changes, you change the code - there's no way around that.

Reply on news.ycombinator.com