I have been developing CQRS-like systems in smaller businesses for a while now. I've also been drawing on Domain Driven Design (DDD) principles. It took more a

I have been developing CQRS-like systems in smaller businesses for a while now. I've also been drawing on Domain Driven Design (DDD) principles. It took more a bit of experimentation to find how best to apply this to smaller scale software, but the results have been very pleasing. I started by sketching out a plan on how I would rigorously apply DDD & CQRS to a problem, but in the full-knowledge that it would likely be overkill. I then dropped out components which I felt were unnecessary for my particular situation. The result has been something fairly lightweight, without too much boilerplate, and very reliable. The clients concerned have certainly found it to be a rock solid part of the core business process. The need for this did not come from any performance requirement, but because I felt there had a to be sensible way to architect SME business software. Especially in a startup environment where business needs and processes were often changing. I felt that DDD allowed me to actually model businesses processes in software, rather than requiring business needs to adapt to the software I was developing. This may well be old news to enterprise-scale developers, but as a freelancer coming from the smaller-company end of the spectrum this was a big deal. As part of this process I developed a Python library [1] to facilitate writing evented/RPCed systems (event sourced or otherwise), and wrote up some very rough architecture tips [2] as part of the documentation. They are pretty high level, but may be an interesting (somewhat opinionated) starting point. [1]: https://lightbus.org https://lightbus.org [2]: https://lightbus.org/dev/explanation/architecture-tips/ https://lightbus.org/dev/explanation/architecture-tips/ Edit: Link update