Yet Another Programming Blog

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. 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 implementation code. We have to refactor so we don't have any logic shared between the tests and the implementation code. This is the main driver of the design. From th

 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 har