Software-Architecture

Overview Chapter 4 of Sam Newman’s Monolith to Microservices tackles one of the most challenging aspects of transitioning to microservices: decomposing the monolithic database. Newman provides practical guidance on managing shared data, splitting schemas, handling distributed transactions, and adopting incremental approaches to achieve database independence. The chapter emphasizes balancing technical complexity with business goals while avoiding common pitfalls. Read Chapter 3 Summary Splitting Databases Incrementally Newman advises against attempting an all-at-once split of the database. Instead, teams should decouple services incrementally: ...

Overview Chapter 3, Splitting the Monolith, focuses on practical approaches to decomposing monolithic systems incrementally rather than through disruptive big bang rewrites. It introduces migration patterns like the Strangler Fig and Branch by Abstraction while emphasizing the importance of balancing technical feasibility with organizational realities. Read Chapter 2 Summary: “Planning a Migration” Read Chapter 1 Summary: “Just Enough Microservices” Incremental migrations Newman argues that migrating incrementally allows teams to learn, adapt, and rollback changes if necessary. Acknowledging that many teams skip refactoring the monolith entirely, he notes that clean-room implementations—building new services from scratch—are often more practical, though riskier when undertaken at a large scale. ...

Summary Chapter 2 of Sam Newman’s Monolith to Microservices is a masterclass in the art of thoughtful planning before diving into the technicalities of a microservices migration. This chapter underscores a key principle: microservices should never be the end goal but rather a deliberate means to achieve broader business and technical objectives. Defining the Why Behind Microservices Newman begins by dismantling the myth that microservices are a silver bullet for every system. Instead, he emphasizes the importance of aligning the migration with tangible outcomes, such as: ...

The Journey to Just Enough Microservices In software architecture, one question looms large over those managing complex systems: How do you rearchitect an existing system without stopping all other work on it? This question, posed in the foreword of Sam Newman’s Monolith to Microservices: Evolutionary Patterns to Transform Your Monolith, resonates deeply with me. It encapsulates the core tension between maintaining product delivery and investing in technical evolution—a balancing act that every engineering team struggles to perfect. ...

One of my favorite things about Golang is the concept of interface. It’s also one of my grievances every time I see them used as C#/Java interfaces. It’s typical to see a colossal interface defined at a package level file, for example, a package that defines CRUD operations for a User. package db import "context" // User -- type User struct { ID int Email string } // UsersDb pointless interface type UsersDb interface { Get(ctx context.Context, id int) User Create(ctx context.Context, user User) User Update(ctx context.Context, id int, user User) User Delete(ctx context.Context, id int) bool } //... then we have the actual struct that "implements" the interface What benefit does this bring to the package? Some say mocking capabilities. From what I’ve seen to mock that kind of package, you need a generator that generates and updates the mocks. ...