Posts

Notes about the Building Microservices

These are notes for my future self about Sam Newman's book, Building Microservices 2nd edition.  Preface Microservices are an approach to distributed applications that use finely-grained services and change, deploy and release them independently. Microservices have become the default go-to architecture when designing system, which Newman finds hard to justify #surprised and want to share his view on why. Foundation Chapter 1 - What are Microservices? Microservices are independently releasable services modeled around a business domain . They are kind of SOA, but the one which is opinionated about how service boundaries should be drawn and where independent deployability is the key. Microservices should implement information hiding and expose their API in some way, e.g. via REST/JSON API or by emitting events. They should have their own database schema. To highlight that the services are as independent as possible, Newman draws them as hexagons, a homage to Alistair Cockburn's H...

Notes about Clean Agile

These are my highlights while reading Robert C. Martin's book Clean Agile: Back to Basics. Preface Uncle Bob starts with a disclaimer. This book is not a work of research. Think of it as a memoir. I knew this upfront and I was looking forward to see him grumbling about what the world has done to his Agile. Big things don't get done by big teams. Big things get done by many small teams collaborating while doing many small things. This is what programmers in 1950s and 1960s new instinctively and this is what got lost in 1970s. Couple of folks reinvented this idea and called it 'Agile'. It has been nearly 20 years from the start of this movement and Martin thinks it is already time for yet another reboot. Acknowledgments I usually don't read Acknowledgments, but these ones have exceptional list of names. It is basically a to-do list for following and reading the mentioned people. Ward Cunningham, Kent Beck, Martin Fowler, Ken Schwaber, Mary Poppendick, Ron Jeffries and...

Notes about the Don't make me think

This is not my kind of book. I usually read books about programming. But the beginning of the book was quite funny. Steve Krug dedicated the book to the woman who laughed so hard while reading this book that milk came out of her nose.  Introduction - Read me first Krug wrote this book for people who cannot afford to have an usability expert in their team. The book is short on purpose - it is more likely it will be used. Krug's definition of usability is: An average person can figure out how to use the thing to accomplish something without it being more trouble than it's worth. This is quite similar to how readability is important when programming. Chapter 1 - Don't make me think This is the first Krug's law of usability. The things we create should be self-evident, so the average people could immediately tell 'Oh, that's a ____'. If you can't make something self-evident, you should at least make it self-explanatory. This reminds me of a Screaming Archite...

Notes about the Test-Driven Development

Notes to my future self about the Kent Beck's book TDD by Example. Part I - The Money Example Kent Beck show us how he works in this part. The routine is: Quickly add a test. When writing the test, we imagine we have a perfect API for our operation. If the first test is too much for us to chew at once, test a smaller prerequisite first. See it fail. Make a little change to make it pass. See it pass. Refactor to remove duplication. We quickly see that by following these steps the problem at hand is divided into very small and simple steps . This is useful e.g. if we are distracted a lot. The tests tell us where to continue. Also the small size of the steps reduces "fear" (how Beck calls it). However we are not forced to do the steps these small. We can go at any speed. But when things get weird, we can fallback to really small steps. I'm not very fond of how Beck calls lots of code smells Duplication . The problem is in dependency between the test code and the implemen...

Notes about Monolith to Microservices

 These are my notes for my future self about Sam Newman's book Monolith to Microservices. Chapter 1 - Just Enough Microservices What are Microservices? Microservices are independently deployable boxes modelled around business domains, which communicate with each other over network. They are form of Service-Oriented Architecture (SOA) which is opinionated about how services' boundaries should be drawn. The services encompass both behavior and data - they own their underlying database and they expose the data via a well-defined API.  Sam Newman stresses that independent deployability is the absolute key. To achieve it, we need the services with loose coupling, which means services should have stable contracts between them. That also means microservices should not share their databases directly. Microservices are modelled around business domains. If done correctly we should almost never have to change more than ones service for any given feature. If we had to, it would be much ha...