Project stakeholders, including executives, business experts, project management, and developers, often ask “how many X are using Event Sourcing successfully?” Here, X might be: Fortune companies; startups; developers like ours; clients; etc. Sigh.
Although anyone’s answer may or may not be comforting, I am pretty certain that this is not the correct question to ask, nor should you be asking me that question. Asking anyone a question like this is much like asking: “Should I invest in the stock market now based on recent outstanding performance?” As you probably already know, the correct answer to this question is: “Past performance is not an indicator of future success.” Actually, the same principle should be applied for any set of patterns and architectural tradeoffs that we choose at any given time. My response will be based on my own confidence to deliver, and I alone will not be able to deliver an entire large system of DDD-based microservices in place of you using your own developers.
You should ask yourself and your team more specific questions, based on the following:
- Each system solution is different, and every team in a microservices environment may be at liberty to select their own patterns, tooling, and single service architecture, based on specific needs. However, along with this the entire system architecture, programming language, and tooling may have already been set by higher-level decision makers. In that case, the languages and frameworks will have a significant impact on the system and project direction.
- Is there tooling available to guide you and provide support for heavy lifting so that you can focus on your business software? Frankly, there has been a very strong trend among those who promote Event Sourcing to condemn, or at least strongly discourage, the use of tools and frameworks designed specifically for Event Sourcing (and CQRS). I think this is largely because of the advanced maturity level of these developers who don’t want extra tools/frameworks getting in their way. I understand. Still, that level of advancement may represent 1% of all developers. Ok, 2%. Well, 5%, but whatever, you know what I am saying.
- Each team will be composed of individuals with different levels of maturity, and teams can be (and hopefully will be) organized around the specific requirements and needs of a given single service and developer capabilities. The same principle is applicable for all microservices and teams used across the system. While experience is helpful, aptitude and ability is key.
- What doesn’t change much is the basic or general requirements of a given system and microservice in question. Thus, you need to put every microservice through the above scrutiny and determine which services will need a specific pattern and which ones will not. Does any given microservice require its data to be persisted in any way temporally? For example, is an audit log necessary for the specific kind of data within a Bounded Context?
- Underlying all of this, however, is the overall system architecture. For example, using a microservices architecture you may determine that the system will be event-driven. Even so, be careful not to conflate Event-Driven Architecture with Event Sourcing. There are reliable ways to be just as successful with event-driven microservices without using Event Sourcing, but you have to be prepared for this approach as well.
Also, even though Event Sourcing has gotten some bad press recently, it is likely that most or none of the above points were carefully considered in cases of failure. We shouldn’t send or accept the message:
You will probably fail with Event Sourcing because I did.
That message is from developers who accept no responsibility for their own contribution to success or failure.
So, before asking me or anyone else for affirmation that Event Sourcing makes sense for your system or any given Bounded Context as a microservice, consider the above. You will be in a much better position to succeed by owning responsibility yourself.
