Amazon calculates a product’s star ratings based on a machine learned model instead of a raw data average. The model takes into account factors including the age of a rating, whether the ratings are from verified purchasers, and factors that establish reviewer trustworthiness.
BBM & Conway Law to end the story made me laugh because my current job involves maintaining such a system. Most of the day I spent writing horrible code. It occurred to me when I started learning .Net Core recently that technology changes suck as I have to update my skills every then & now. So I tried to give another try learning DDD after giving up on DDD couple of years back. So I started reading Eric Events Blue Book which is thick & has a lot of thought-provoking theory. I only read the first 7 seven chapters. Then started reading Jimmy book last week along with watched Plural Site videos as well but was burdened with "It depends on analogy a lot". Enough with history but this book is so refreshing that I actually want to write code & experiment it. I love the idea of using a rather simple domain like Ad application. I am no DDD practitioner because I have failed multiple times in the past just to keep EF Context out of my Domain Model rather I should call it Persistence Model. The key takes away from this book is: - Event Sourcing is not really difficult to implement as it sounds in start - Aggregate & Context Boundary was explained very well with a crisp example What this book lacks: - Event Sourcing downsides when there are changes to the model, perhaps an Entity is completely removed, or associations are changed in a way that it requires changes to existing data, like new property is added. - How to fix bugs since Aggregate is persisted to the event stream. Is it just like adding another event to stream so the state can be corrected like debit/credit? - How to fix Legacy systems, perhaps complete rewrite, but who will listen to an inexperienced DDD developer? Note: This is an initial review, I will be reading it slow & implementing what is being told, and see how I feel.
I haven't quite finished this book yet. I have read a few books and I'm always worried that they will go on and on about technical terminology and how it's going to save the world of software, but then you're left with an extremely vague representation of what something is. Anyway, as complex as people say DDD is, this book explains it very tersely. It makes sense and it's framed in a very coherent way with a great example. The fact that the book goes deeper into implementation than most will need, seeing it isn't confusing nor is it distracting. Everything is explained right there with modern code snippets. While I personally still see DDD as a pick-and-choose(depending on the complexity of your problem, your ORM, etc.), the book does a great job of explaining everything, and dissecting other methods like unit-of-work and showing their flaws. The author is aware and accepting of the fact that not every user needs every aspect of DDD. It's easy to continue on through the entire book if you aren't implementing something so similar, and the level of depth is quite deep for those who need it, and as a reference for those who may eventually. The book also couples testing and things like OpenAPI for a very modern approach.