Hacker News Reader

Comment by blobman | Hacker News Reader

I refactor my code fairly regularly (as specifications change). The use of TDD, DDD, CQRS and Event Sourcing gives me immense flexibility to be able to refactor a large codebase and then test it through its whole lifespan (with actual data).

View on HN

> The use of TDD, DDD, CQRS and Event Sourcing gives me immense flexibility to be able to refactor a large codebase and then test it through its whole lifespan (with actual data).

What is your experience in applying those principles in a team? It would be very interesting to get some insight on it.

1. TDD is simple enough. Everyone should be doing it. 2. DDD - this usually results in plenty of healthy debates on naming conventions. Acronyms are abhorred and we try to agree with the stakeholders on the meaning of each word they use. 3. CQRS and Event Sourcing - this has required our team quite a bit more of startup time than a CRUD application would have. We have been lucky to have a very understanding Product Owner who gives us plenty of time to deal with tech debt. Although single features may have originally taken us longer (than the time it would have taken to do the same with CRUD) at the start of the project, years on this time and the complexity of refactoring or adding features has not really increased, as any functionality is contained within its bounded context.

The biggest difficulty has been explaining what we are doing and why to senior management. But we haven't had any bad incidents so far, so I think they like us.

Do you do full-blown event sourcing or apply it to specific areas only? If the latter, how do you decide which? How do you deal with performance? Specialized database (e.g. Event Store) or not?

Real life success stories about ES are rare, so I'd love to get more insight in the anatomy of the solution (way beyond these few questions). Blog post request, I guess.

We have full-blown event sourcing for pretty much everything. The performance on the read side is great (obviously). We have an Event Store and we rebuild the Domain for every new command, so it isn't particularly fast, but we have a situation where commands are only issued a few times every year by a single person, whereas there are millions of reads every day (hence justifying CQRS as a solution). We have a mixed solution around replaying events though, largely around the issues we have with file uploads. Every file upload triggers multiple events (uploaded, processed etc) and we have different solutions for different files. Small files we store in the events as a blob, whereas big file events upload the data to a projection store and will not be replayed, so we don't have the issue of having to keep the original files forever as well as the database. I should probably write a blog post about the project at some point, but I'd like to investigate with my bosses as to how much I can actually reveal about the domain (because it would make the read so much more interesting if I could say everything).

Reply on news.ycombinator.com