Thanks for this comment. It is important to consider everything you said. CQRS is part of this book, but it is more of an explanation and might help you at some point (but does not need to). I think that's the main problem of CQRS - it is not understood well.
Throughout the book, I describe many concepts. Sometimes, I give some recommendations, and sometimes, no.
I accept your note—these four steps of evolution help you find yourself in one of them. Simplicity can be solved in multiple different ways; it is just the direction of keeping the solution as simple as possible (sometimes it will be more complicated, and sometimes less).
Enjoy reading it; if you don't like it, you can always return it within 60 days (Leanpub policy).
Thank you! This would not have been possible without stopping almost all other work.
This is my tip: if you want to write a book, plan unpaid holidays, or stop all consulting/freelancing work. Then, it is not that hard to keep up the tempo - when you know what you are writing about, of course ;)
I have similar observations, and over the years, I kept looking for something that would stand the test of time. I still remember horrors related to documenting architecture in Word documents (and requirements in Excel, omg).
The architecture decision log usually works well for the teams I work with. It is kept up to date and ordered thanks to architecture decision records.
I describe it extensively in one of the book's chapters with a practical example. I also show how to document alternatives considered when the record was added, where to keep it in case of mono repo, multiple repos etc.
I partially agree with you- nothing is better than working on "your own" mistakes, but some mistakes often repeat in software architecture. Why not take advantage and not repeat them by learning from others' mistakes? :)
Thanks for the tip! The book describes the approach that helps prevent my mistakes, and in each "step," I add several warnings and information sections about what to do and what not. I will try to think of how to add a better demo.
I tried to keep writing daily—sometimes for just 4 hours, sometimes for 13. On average, it was more than 8 hours a day, with some longer (1-week) breaks in between.
I will write another post on writing experience in the next few weeks :)
