Strategic Monoliths and Microservices: Driving Innovation Using Purposeful Architecture (Addison-Wesley Signature Series

Vaughn Vernon Signature Book

by Vaughn Vernon, Tomasz Jaskula

Most recent microservices books fully buy into the hype, starting from the premise that microservices are nearly always the best approach to developing enterprise systems. But that isn't always a safe assumption: in fact, in some cases, it can be disastrous, leading to architectures that serve nobody well. Strategic Microservices and Monoliths helps business decision-makers and technical team members collaborate to clearly understand their strategic problems, and identify their optimal architectural approaches, whether those turns out to be distributed microservices, well-modularized monoliths, or coarser-grade services partway between the two.

Writing for executives and IT professionals alike, leading software architecture expert Vaughn Vernon and Tomasz Jaskula guide you through making balanced architecture compositional decisions based on need and purpose rather than popular opinion, so you can maximize business value and deliver systems that evolve more easily. Throughout, the authors provide realistic application examples, showing how to construct well-designed monoliths that are maintainable and extensible, and how to decompose massively tangled legacy systems into truly effective microservices.

Genres: Technology, Architecture, Programming, Software, Business, Nonfiction, Computer Science

352 pages, Kindle Edition

Published October 27, 2021

Reviews

[Henry Suryawirawan · Rating 5 out of 5]

First, I'd like to mention that this book doesn't cater to just software engineers and architects, but it also provides great insights for C-level and executives about this latest architecture buzz in the software industry, i.e. monolith vs microservice architecture.

The book starts by reminding us of the importance of developing strategically significant software that produces breakthrough innovations, rather than a steady stream of shiny new technical products. A lot of techies these days start with shiny solutions rather than thinking about the strategic innovative business aspect of software development, i.e. to be more purposeful in choosing technologies and architecture. It also covers other important aspects, such as embracing failures, Conway's Law, and the approach of "module first, deployment last"–a more sustainable approach to software development.

The book then gradually moves towards the more technical discussions, introducing readers to concepts, such as Domain-Driven Design, Events-First Architecture, ports & adapters, and embracing latency. I find the discussions about these topics are super insightful as one tries to decide what kind of software design and architecture they should adopt for building a software system that earns for the business and is supple enough to change over time.

The last part of the book tries to answer the inevitable question, whether we should choose monolith or microservice architecture. Fortunately, the answer is not a binary and there are many decision factors that drive which architecture would work best for your context, but one thing is for sure, the Big Ball of Mud monolith is certainly bad!

To end this review, I would like to include the following quotes which I found summarizes well regarding the monolith vs microservice debate.
"Monoliths are damaging when poorly designed, and Microservices are disastrous when misappropriated. An architecture is good for its intended purpose. Purposeful architecture is the best architecture."

PS: If you're a podcast listener, you can listen to my great conversation with Vaughn in Tech Lead Journal podcast episode 71 (https://techleadjournal.dev/episodes/71/) discussing the book in more details.

[Mark Seemann · Rating 3 out of 5]

Even before I finished reading it, I'd recommended the book to one of my customers.

My customer was requesting my help with strategic software architecture improvement, and that's not really my core competency. Strategic Microservices and Monoliths, on the other hand, is exactly about large-scale innovation in software architecture and business execution.

It outlines how to identify and set organisational goals, how to use strategic learning tools, how to drive business innovation, and whether a well-implemented monolith is more or less appropriate than a microservices architecture. It covers event storming, DDD, large-scale refactoring, and event-driven architectures in the large.

It also covers how psychological safety and licence to learn from failure is essential to strategic innovation.

It all seems reasonable and aligns well with what I already know about the topic. It is, however, so far removed from my area of expertise and interests that I'm not sure how to rate it.

The book seems mostly to be aimed at high-level decision makers and enterprise architects. I'll recommend it to its target audience.

[Goce Bonev · Rating 5 out of 5]

A holistic view of modern Domain-driven Desing evolved and applied on every level, from technology to business, communication, and culture. This is a great book for CTOs, architects, and senior developers that have or plan to take the architectural path. It shows how to approach real-world problems with a clear head, how to reason about potential solutions, and how to stay focused on things that provide value when surrounded by hype.

Looking forward to the next book "Implementing Strategic Monoliths and Microservices".

[Paulo Merson · Rating 5 out of 5]

Well-written, clear language, enjoyable to read. I particularly like the explanation of context map patterns (conformist, ACL, etc.). The examples and clever illustrations make this sometimes overwhelming topic easy to understand. But I got the most value from the description of the Ports and Adapters (aka Hexagonal) architecture pattern. I'm a developer who has used hexagonal for a while. I also teach software architecture and I have looked for good descriptions of this important pattern to give students as a reading assignment. Chapter 8 has the best description I've seen. It properly explains the pattern, discusses the tradeoffs, and goes on to describe four different ways the application (inner) layer can be designed.

[Aleix · Rating 5 out of 5]

A book so needed by the software industry and focusing on what's more needed, a book with a software perspective that addresses the business.

Vaughn and Tomazs made a book accessible a complex topic as is strategic thinking towards Software Development. A book that helps not only Software Developers but people in other fields to __make the right questions to address the high-value business initiatives__.

I do recommend this book to any software developer, architect, tech lead, or principal that works on complex domains. It gives you the right perspective and the tools to address these problems from a Strategic point of view.

It's important that it gives _how_ and _why_ you should make decisions based on business. That's what makes more valuable the decisions made by engineering leadership. This book doesn't include the implementation part, which will come later in the next book, yet understanding this part is crucial to later have high-impact implementations. Without this good reasoning, it doesn't matter how good is the implementation if you are implementing the wrong thing.

I hope you enjoyed it as much as I did! Already applying concepts in my day-to-day

[Brutalbrian · Rating 5 out of 5]

To me, DDD and the corresponding "Sociotechnical sympathy" - i.e. ensuring architectural and organizational alignment (e.g. autonomous feature teams) is the key to digital business agility, and the book guides the reader onto the right path, giving concrete advice on how to avoid the all too common pitfall of going down the Microservices way without considering why.

In many cases, a Monolith is the right choice, and Vernon and Jaskula provides you with tools to realize when and why!

[Jakub Zalas · Rating 5 out of 5]

Authors throw a bucket of cold water on those still riding on the hype of micro services. They draw the line between the big ball of mud and modular monoliths, while providing the context and motivation that could drive us to micro services. Their book brings together tools needed to focus on learning, experimentation, and creating teams that build successful products.

[Miha J · Rating 5 out of 5]

I recommend this book to anyone involved with software development in any role possible. It's a book for the whole vertical of people in the company. It gives management a clue about how complex the software development is, the traps, the why's, and what they want to pursue. It guides how to think about software development and resist the urge to write code and prototypes first.

I've been involved in projects where the initial team overengineered the initial system. They went to conferences, read books as bibles (recipes, patterns practices), and designed the system so complex we are still struggling to understand it. We are replacing it bit by bit, trying to get around the initial idea and architecture. They started with microservices from the get-go and wrote their infrastructure code. It's fun to play with "toys"! They wrote their multithreaded application because it's fun. Their domain is pretty straightforward, but they complicated it so much that it hurts. Anyway, after 100+k lines of code later, we need to maintain and develop it further; every step is hard and takes a lot of time. We are merging "microservices" to monoliths!

Another issue is "Sales-driven development." Sales get to the customers, and they sell this and that, nobody asked anything development much with weak or wrong estimations and unrealistic promises, etc. Small companies tend to be like this, trying to get as much business as possible with some custom modified solutions, but that not scalable or maintainable on the long run if they want to cater everyone with the anything they desire. We started to put boundaries; we need to set the focus on core domains and build value around that. Not just go around and sell a swiss army knife that does not provide much value, and it's a burden to the development team.

Book Strategic Monoliths and Microservices makes so much sense to me. I am applying the principles to the greenfield project where we wait for the implementation details as much as possible.

Thank you, Mr. Vaughn and Mr. Jaskula, for a great book with many insights! You can explain complex things in a way we understand. I am looking forward to the next book.

[Gabriel Santos · Rating 4 out of 5]

Following my way of review I have to say that despite being a very good and insightful book, I did not enjoy the over exemplified part. However you should notice that this is a matter of personal taste. Most of the time I had already understood and had a feeling that the book was too dense.

All in all, it is a rather good and interesting book, specially the first part that brought some more strategical insights on understanding the impacts of architectural decisions on the business.

[Brian Barnett · Rating 5 out of 5]

Just finished reading the book "Strategic Monoliths and Microservices: Driving Innovation Using Purposeful Architecture" by Vaughn Vernon and Tomasz Jaskula. It fills a much needed gap in the conversation around software architecture today.

Unlike other software architecture books, which are more technical in nature, this book really gets into the why and how your organization can strategically innovate to establish a digital transformation.

The book is meant for C-level and other business executives, as well as every role and level involved in leading software development, including software architects and dev team leads.

It doesn’t go in-depth into technical implementation. That is saved for the next book, "Implementing Strategic Monoliths and Microservices"

It outlines how to identify and set organizational goals, how to use strategic learning tools, how to drive business innovation, and whether a well-implemented monolith is more or less appropriate than a microservices architecture. It covers event storming, DDD, large-scale refactoring, and event-driven architectures.

It’s a book centered on software architecture being an integral part of business strategy.

The authors make it very real and practical by using a fictional insurance company, NuCoverage, and a digital transformation business scenario throughout the book, providing real world examples of how to apply the techniques and ideas presented.

A few quotes from the book:

“Steve Job’s advice: “You can’t look at the competition and say you’re going to do it better. You have to look at the competition and say you are going to do it differently.”

“Imitation is not a strategy. Differentiation is.”

“One of the biggest problems in software development is developing functionality and features within software that have little to no value to the business.”

I highly recommend this book as well as the other books in the Vaugh Vernon Signature Series. Top quality authors and content.

[Christoph Kappel · Rating 4 out of 5]

This is a great book about the usual debate to either go for monolith or to use microservices like everyone else. It brings in some interesting points like FOMO in regards to tech and also summarises many other must-reads like Team Topologies: Organizing Business and Technology Teams for Fast Flow. I especially like the mention of ADR and the examples - I think we really need documentation like this in our industry.

One of the things I don't like is the kind-of difficult (at least for me) to understand insurance domain in the examples and also the many mentions of the upcoming book ( Implementing Strategic Monoliths and Microservices: Patterns and Practices for Continuous Improvement- it sometimes feels like you got only half of the text.

[Diego Sogari · Rating 3 out of 5]

Disclaimer: I only read the first half of the book.

I - The criticism

I have mixed feelings about this book. Sometimes, it seemed like the authors tried to bulk up the content, whereas it could have been written in half the length and cost half as much (and be twice more palatable). At other times, however, it brought about some interesting stuff that I wasn’t aware of. So far, I wouldn’t recommend it, but I’m hoping that the second half will change my mind.

For one thing, it lacks clarity and focus (perhaps, practicality or straightforwardness are the words here). The authors present a lot of ideas about communication patterns, with various modeling elements to map them, but we’re often left with a sense that they are too abstract or cannot be readily applied to our case. For example, where is an example of the application of Topography Modeling? Did the authors actually used this tool in their professional work?

Then, the style of the narrative contributes to this effect. It seems bloated with unneeded phrases and mannerisms. Oftentimes, a sentence could be rephrased more simply, or entirely removed from a paragraph without loss of meaning. Consider the following: “A Bounded Context is often the source of information needed by one or more other collaborating Bounded Contexts in a common system solution, […]”. Compare it to: “A Bounded Context often emits information that is needed by other Bounded Contexts in the same system, […]”. Then they go on: “To avoid this predicament and enhance the exchangeability of pertinent information, […]”. Which could be rephrased as: “To ease the consumption of exchanged information, […]”.

Additionally, the Executive Summaries between chapters feel like page fillers, as they just repeat what will be discussed ahead. You may want to skip these when first reading the book, though they might be useful afterwards, when revisiting.

Finally, regarding the print quality: it’s not great. The paper is thinner and the ink is fainter than in most other books of this kind (even from the same publisher).

II - The praise

One good thing about the book is that the content seems well edited and revised, there being very few errors or typos. It is also well organized into parts and chapters which reveal a coherent storyline.

Furthermore, there are great insights scattered throughout, if you are patient enough to distill the bulk that surrounds them. You can also hear many of these on episodes no. 21 and 71 from the Tech Lead Journal’s podcast, in which Vaughn talks about this book and gives great words of wisdom.

Finally, I think the authors did a really good job of explaining the business perspective of organizations, which is helpful for introvert engineers (like myself). The order of the chapters should tell on the causal relationship between business needs and the systems designed to impact them.

III - Some key points

Good:
- nice compendium of different subjects, which are covered in more depth in related books
- more than a handful of useful insights, some of which are summarized at the end of each chapter
- mention of various tools and frameworks that can improve our effectiveness in our profession
- up-to-date with trends in software development practices and technologies (as of 2022)

Bad:
- lack of conciseness
- high levels of abstraction of some topics
- overly decorated prose, with repetitive terms (e.g., strategic, innovative, differentiation)
- due to the above, a tiresome reading overall

***spoiler alert***

Insights:
- awareness of Conway’s law as a constraint on systems design
- use of decimal floating point for financial calculations
- coupling and cohesion only matter when the frequency of change is high
- technical debt metaphor: the debt has to be paid at some point
- responsible decisions are made at the last responsible moment

Highlights:
- practice of safe experimentation and cheap failures as a means of learning
- (continuous) knowledge is one of the organization’s most important assets
- communication is a driver for breakthroughs in innovation, which is the most important aspect of digital transformation
- a business capability should match one subdomain, while being delimited by one bounded context and driven by one team

[Scott Hannen · Rating 5 out of 5]

TLDR: This is insightful and readable. I especially hope that decision-makers in the "hierarchy" of organizations that depend on software will read it.

Most companies don't realize how much the issues with their software development processes cost them. This might be because they use software but don't see themselves as software companies. Perhaps they gain some value despite the flaws in how they develop software but don't realize how much more they could accomplish. I think an underlying problem is that both as organizations and as developers we don't know that "better" exists, or we suspect that it does but we don't know what it looks like.

This book shows what "better" looks like. It gets into specifics of application design and architecture, but not until it lays some foundation. Our software must support the needs and goals of our business. If our software becomes tangled and hard to understand then it can't support innovation, and it's difficult to grow and change.

It emphasizes how the state of our software reflects the way we communicate - developers with developers, business stakeholders with developers, and teams with teams. Then it offers specific ways to improve that communication. This includes an excellent chapter on how everyone involved can collaboratively determine what the software should do on paper (stickies), setting it in order, discovering and discussing issues, all before the more costly work of writing code begins. This process also allows us to reveal and document opportunities we may have missed.

That alone is worth the price of the book. It describes a way of thinking and operating that's beyond what most companies do but within reach.

After that it deals with decisions regarding application architecture, including microservices and monoliths. All of this builds on the foundation: How will these decisions support the needs and goals of our organization? How will they enable innovation?

I've struggled with some concepts of domain-driven design and I tune out when I hear the words "bounded context." The book doesn't dive heavily into these concepts, but they are addressed and made them accessible. I understand a lot more than I did before.

I lost track of how many times points mirrored my own observations. For example, developers tend to get sidetracked writing custom library code instead of using avaialble tools which are usually free. This does not contribute in any way to the goals of the organization. But why do they do this? Because they need to solve problems, and if the organization doesn't involve them in solving its problems then developers invent their own.

The book delves sufficiently into domain-driven design and architecture without going in-depth. It refers to a forthcoming book that deals more the implementing architecture. (I'm looking forward to it.) But it does not by any means short-change those subjects.

It's very readable. Reading it was enjoyable, not work. I couldn't help recording lots of notes, and I sincerely hope that more people read this.

[Dan H · Rating 4 out of 5]

3.5, rounded up

This is a good book where the content, if applied appropriately, should lead to well-architected systems. My concern throughout the book is that it feels like DDD/CQRS/ES (including the author's own product) indoctrination by stealth, given that the title and blurb do not mention any of these things, although I accept that the authors are well known in this space. My fear is that those lost and looking for answers about microservices will come out from this book and want to apply event sourcing to everything, which is the same problem in a different form.

In fairness, the authors do press upon developers to think critically about monoliths/microservices and make decisions which are best for the business. They don't seem to extend this critical thinking to their own tools & techniques because the book would lose authority, but hopefully readers of the book can read between the lines and do that themselves.

From a DDD perspective, this book is far more accessible than the "blue book" (I haven't read the red one). In the first couple of chapters it felt like "DDD for execs" but as the book continues it becomes more technical so I wouldn't recommend it to non-developers. I do wish that technical books would use something more interesting for examples than finance/insurance but that's a personal preference :)

I can say that I learnt some things from the book and I have used the terminology from "context mapping" in my day job since reading it. I will most likely pick up the planned sequel when it comes out.

[NiktTaki · Rating 3 out of 5]

Very good software architecture book, bad marketing tool.

As other reviewers have already mentioned, it's a very good book about software architecture that will suit not only coders but also people generally involved in software development and decision making. It approaches software architecture through various lenses throughout the chapters: through the eyes of entire teams, individual developers, architects and business stakeholders.

However, there is one caveat- the terrible marketing that the authors decided to embed into the book. Literally every 5 or 6 pages (sometimes more often), expect to read almost the same sentence recommending authors' next book, like that song you really don't like but can't get it out of your head. I would give this book 4 stars, but had to drop the rate by 1 star because of it.

[Radek Maziarka · Rating 4 out of 5]

Domain-Driven Design applied to the monoliths and microservices, provided in a very accessible way. I really enjoyed strategic parts about how to start with working on the architecture - Conway's Law, Cynefin Framework, Impact Mapping, or other laws and techniques. In that way, it all combines into a logical whole. I must say that this book provides probably the best explanations of Context Maps and how to use them in the field.

I reduce my rating by one point, for the Modeling chapter (about aggregates / vo / entities) and the Message-Driven Architecture chapter - they are too shallow to provide any meaningful insights.

I look forward to reading the next book - about implementation of these patterns into the code.

[Jef Claes · Rating 5 out of 5]

Even though a lot has been written about DDD and other tool sets, this book views old and more recent models through a lens that has been underserved. The authors succeed in breaking down how software architecture should not only support the business, but how it can be a key enabler in transforming the business. Half way through, the authors touch on some more tactical patterns, to eventually put the "question du jour" to rest using the guiding principles they've explored throughout the book.

[Matt · Rating 3 out of 5]

I didn't finish this book because I lost access to O'Reilly Online, but I got about a third of the way through it. The content was decent, but I think it's telling that I did not feel compelled to go get a copy of this book when I lost my access.

[Matheus Marabesi · Rating 5 out of 5]

This is one of the books that I read and it it was the perfect fit for the moment of the reading and the project I was working. Much of the book (as expected) is around DDD, monoliths and event storm - with a bit of microservices.

This is a more through review from the book with some quotes (https://www.codurance.com/publication...) but, here goes some takeaways:

- Microservices for some reason are hype and monoliths were converted in something "bad"
- Adopting microservices come with trade offs that are usually ignored (async communication, distributed tracing and so on, sam newman shared more info regarding that)
- The decision to go for microservices or not, should be backed by business purposes (thus the name of the book "purposeful architecture")
- Domain Driven Design and Event Sourcing is used heavily to depict the approach of discovery the "real" business needs
- Throughout the book, the monolith and later or the modulith are the approaches recommended most of the time
- Legacy systems that are monoliths carry the risk of never being retired because of business needs. Maybe this one could benefit from Patterns of Legacy Displacement as an alternative
- The strategy to shift to microservices implies that the application is a modulith with defined boundaries (again DDD is used)