Books are the best way to convey knowledge, especially when they aim to share a holistic mindset or point of view—those books that make your mind explode. However, the more books you read, the harder it becomes to be awed. At some point, you might notice that some books could have been better if they had drawn from others, or that one book contradicts another.

I’ve recently read a couple of books about software architecture. I really enjoyed reading them and would recommend them. Many decisions I make when developing software will be supported by what I learned from those books. But on the other hand, I think they were missing critical pieces, and the mindset they tried to convey felt weak. They seemed to play it too safe, failing to provide a complete compass for navigating software architecture. There were no clear sets of principles or directions.

Other books are much clearer about the knowledge they want to impart to improve your life—in the context of software engineering, at least. For example, DevOps books strongly advocate for making IT work closely with the rest of the company and for automating the development process. Similarly, DDD books—the few that are out there—emphasize the importance of strategic patterns. They take a domain-oriented view of the big picture, focusing on bounded contexts, design, and treating technical aspects as secondary, almost mechanical tasks once you grasp their technical patterns.

This kind of advice is missing from software architecture books. While there are subtle hints, they’re non-committal. The only strong takeaway is, unfortunately, an obvious truth that’s useless if you’re looking for real direction. These books could have gone further by integrating the DDD perspective. Doing so would render many of their discussions irrelevant or obvious.

And that’s what I aim to do in this blog post. I want to bridge the gap between a DDD + DevOps mindset and these books by offering a holistic approach to software architecture. This is the approach I use, the mindset I’ve developed. It’s one that these books helped shape and that my experience has consistently validated as the right path. I didn’t create this mindset—it’s shared and spread across four or five books (primarily) that I’ll reference below, written by people far smarter than I am.

I’m going to commit to this approach. I’ll go as far as to say it’s better than others, and that other approaches are wrong. This kind of boldness is what I found missing in those software architecture books. Of course, bold statements require justification—otherwise, they’re just dogma, and no one wants to deal with blind fanaticism. But there are reasons, and if you’re writing a book, you have the space to explain them. Doing so in a blog post is a tougher challenge, let’s see how do I do.

The first law of software architecture

The only strong statement made in the book is the first law of software architecture:

Everything in software architecture is a trade-off.

I don’t disagree—it’s completely true. But it’s also useless if you’re looking for direction. Worse, it can be dangerous, as it lends validity to every possible option under the assumption that each one has its own advantages.

This “law” essentially describes the act of choosing or deciding (it’s the definition!): every choice comes with both advantages and disadvantages. What a strange field software architecture is! So different from any other decision in life, right?

Let’s take this idea to the extreme. I could decide today to rob a bank—or not. The advantages of committing the crime might include an adrenaline rush (if I’m that kind of person), becoming richer if I’m not caught (though probably neurotic from constantly looking over my shoulder), or even gaining fame if I am caught, which could have its uses. Of course, the downside is significant: I might go to prison. On the other hand, not robbing the bank has its own disadvantages—I’ll be less wealthy and will have to earn money through likely more effortful means.

But why waste time considering the pros and cons of this trade-off? If I had a set of principles (moral principles, in this case), I wouldn’t even entertain the idea of robbing a bank! My choices would be limited to those that align with my principles. Sure, there are always gray areas—there always are. (What if the bank were owned by an evil, dictatorial regime? There’s your next movie plot!) But having a set of principles helps you identify the best course of action—or at least understand what it would be—even if you don’t choose it.

This brings us to an important point: when making decisions, there’s an entire range of options that should never even be considered because they violate key principles. We can confidently say those options are wrong or invalid. Yes, wrong. Of course, you can always find some advantage to anything if you try hard enough—but that’s unhelpful and a waste of your time.

Even within the range of valid options, though, some are objectively better than others. Imagine you’re shopping for a car. The Toyota Corolla is famously robust—it’s said that even if you pulled one from the bottom of the ocean, it would start right up and run. Now imagine there’s a car just as robust as the Corolla, but as safe as a Volvo and as fast as a Ferrari. That car would be objectively better than the Corolla.

Yes, there are still reasons why I might choose a different car—even a “lesser” option. I might even consider options that don’t align with my principles and end up choosing one of them. It happens. But the key is being aware of this, and striving to rectify it in the future.

To illustrate the importance of knowing when you’re crossing boundaries, let’s consider the decision between microservices and monolithic architecture. (I’ll argue later that this decision is actually less important than it seems.) This tables are extracted from the first book Fundamentals of Software Architecture:

On the left we have the star rating of microservices and on the right a monolithical architecture. I used the 3 layered ratings since it was the one that the book hinted to represent a monolith.

One major pitfall of the trade-off mentality is that the options are rarely MECE (mutually exclusive, collectively exhaustive). A classic example of a MECE list would be the available flavors of ice cream in a shop: vanilla, chocolate, strawberry, etc. However, in the real world, options are rarely so neatly categorized. They tend to overlap, build on each other, or combine in unexpected ways. For instance, there’s nothing stopping you from putting a 3-layered architecture inside a microservice!

So, what’s the trade-off in that case? For any trade-off analysis to be meaningful, you must frame the problem correctly. Instead of trying to analyze incomplete or overlapping options, your time is often better spent creating the best possible option—like inventing a new ice cream flavor that wasn’t available in the shop, perhaps with an entirely different recipe. It’s a creative process, not just a mechanical evaluation of pros and cons.

At first glance, the obvious choice seems to be microservices. Look at all those stars! However, one could argue that if overall cost or simplicity is more important to you, then you might lean toward the monolith on the right.

Simplicity and overall cost aren’t inherently better in monolithic topologies—a common misconception. In fact, simplicity is independent of this decision entirely (yet another trap). What determines simplicity is good design, not the choice of the topology.

As for cost, it all depends on how you measure it. For example, a monolith’s low star rating for “deployability” suggests frequent issues during deployment. Similarly, low modularity can make the system hard to extend. But these problems aren’t architectural in nature—they come from design choices. And how costly are these issues? Perhaps the infrastructure is cheap, but the human cost—due to debugging, delayed deployments, or maintenance overhead—is 10x to 100x higher, making the monolithic topology far more expensive than microservices in practice.

But hold on—should I base my decision on overall cost? Or simplicity? A set of principles or a clear direction would clarify which aspects are most relevant, the ones I should prioritize. Let’s set aside simplicity for now, as I can’t argue against it—even for the sake of this example. Simplicity should always be one of the core principles underlying any decision, as it goes deeper than DDD or any specific mindset. So instead, let’s focus on overall cost.

Overall cost isn’t really an architectural concern. Returning to the car analogy, we identified the “best” car (microservices), but we might still choose the Corolla (monolith) due to budget restrictions. And that’s fine—as long as we acknowledge that the other car was objectively better from an architectural perspective. There’s nothing inherently “architecturally” superior about a monolith in this scenario, so choosing it would make for a suboptimal architectural decision. The only valid reason for choosing it lies in constraints outside the realm of architecture.

External constraints, ideally, shouldn’t influence architectural decisions. Of course, this is easier said than done. We don’t have infinite budgets, do we? But it’s important to recognize when such constraints are affecting your choices, because addressing them outside the trade-off itself might ease the decision-making process. Here are the main disadvantages that, ideally, shouldn’t carry weight in architectural decisions:

• Budget: Ensure the actual cost of each option is calculated properly. For example, as I explained in a side note, a monolithic topology could actually turn out to be more expensive than microservices in the long run..

• Time Constraints: Ideally, you shouldn’t let time pressure dictate your choice. That said, the perceived difference in time-to-delivery between microservices and monoliths can often be overstated or even negligible.

• Lack of Experience: Simply gain the necessary experience and reevaluate the trade-off. Continuous learning and improvement are essential for everyone in this field.

• Complexity: Complexity is undeniably bad—but are you sure it’s real complexity and not just resistance to change? Developing a microservice is often easier and simpler because you’re working within a smaller subset of the overall system. You don’t need to think about the entire system at once. This is true even in a monolith when developing a well-isolated “module.” So, are microservices truly more complex, or are you simply unwilling to learn how they work?

Broadly speaking, these concerns fall into two categories:

1. Company/Organization Mindset Concerns: Factors like budget and resource allocation reflect the organization’s overarching priorities and willingness to invest.

2. Team Effort Concerns: Good solutions require effort. Want to get fit? You’ll have to put in work at the gym. Similarly, the effort required to implement a solution should never be counted as a disadvantage in a trade-off. Effort is the price of quality.

The principles

We’ve established that trade-offs are meaningless without principles to guide us in determining what’s truly important. But what should those principles be? The books provide some guidance:

The responsibility of the architect is to choose the option with least worst set of trade-offs

How do we determine the "least worst" set of trade-offs? As the books point out, each situation is unique, and not all principles will apply universally. What follows should be taken as guidelines rather than rigid rules.

To be clear, I didn’t invent these principles. They are drawn from a collection of books that offer far better and more detailed justifications than I could provide here. My goal is to complement the material in Fundamentals of Software Architecture and Software Architecture: The hard parts by addressing what I believe are their missing pieces.

Everything starts with the domain

The first and most foundational principle is to place the domain at the center of the development process. Every decision should flow from this focus. What is the domain? It’s the core problem your organization is trying to solve. For example: a shipping company’s domain is shipments. If it produces and distributes doughnuts, then it’s about that. Selling tickets for concerts. Developing drugs. Giving any kind of service. Accounting systems. Each game. It all has domain.

This of course comes from Domain-Driven Design which was published on 2003 by Eric Evans. If you browse Evans’ book, you’ll see an extraordinary effort to represent domains visually through diagrams. Here’s an example:

These diagrams attempt to capture the essence of business domains in various contexts. Notice that, up to this point, I haven’t mentioned anything about technology. No programming languages, frameworks, databases, or platforms have been referenced. Why? Because designing the domain is entirely technology-agnostic**.**

You might notice that many of these diagrams are UML. While I believe identifying objects and modules is essential—and UML provides useful tools for this—it’s not critical to create a "university correct" UML diagram. Treat UML as a means of communicating with others about how the code is intended to function, rather than an end in itself.

Additionally, these diagrams may give the impression that domain design is exclusive to Object-Oriented Programming (OOP). That’s not the case. The principles also apply to the functional programming paradigm, provided you focus on designing the appropriate types. Ultimately, it’s all about effectively designing and modeling the domain. For more about FP and this, read this blog post

Clean architecture

After identifying the processes, workflows, and functions of your business and translating them into well-thought-out beautiful diagrams, it’s time to implement them in code. Of course, this is easier said than done. Fortunately, there’s another awesome resource to guide this stage: Implementing Domain-Driven Design by Vaughn Vernon. Published a decade after Eric Evans' work, Vernon’s book dives much deeper into the concepts and their implementation.

This stage remains technology-agnostic. Frameworks, databases, programming languages, and even deployment topology—whether you use a single service or multiple microservices—are still irrelevant at this point. Well, we’re writing code now, so you will need to use a programming language now, but just that!To properly implement DDD patterns, we must avoid coupling ourselves with infrastructure concerns such as databases or frameworks. This is where clean architecture becomes a must.

Clean architecture (also referred to as onion architecture or hexagonal architecture) is based in the principle of separation of concerns. It emphasizes keeping the domain (also called “business rules” if you don’t like the word “domain”) completely free of any infrastructure or framework-related dependencies. For more information about this, read this article. This separation ensures that domain logic stands independently, unaffected by changes in technology or implementation details.

I will from now on refer to that as clean architecture, as it’s the one explained in the Clean Architecture book by Uncle Bob and it’s the one with a most relaxed approach, including the other variants.

Let’s distinguish between the different levels of architecture. The following categorization is my own, so it may lack some rigor. Imagine these levels as concentric layers:

1. Outer Layer: Topology
   This is what’s typically referred to as "software architecture" in books. It includes decisions about deployment, such as whether to use a single executable or many (the "quanta" concept from the books).

2. Middle Layer: “Code” Architecture
   Here we decide how to structure the application itself. Options include clean architecture, using a specific framework (e.g., Java Spring, Python Django, or PHP Symfony), or just spaghetti code.

3. Inner Layer: Design
   This is the core of the architecture, where domain-driven design lives. It focuses on how the system is modeled, how the logic flows, and how business rules are encapsulated.

As mentioned earlier, the only way to have a clean design—one that’s free of any technical concern—is by choosing clean architecture in the middle layer. Any other approach, like using a framework or basing your design on infrastructure decisions (e.g., the type of database), will compromise the purity of your design. That’s why the diagram above looks like any clean architecture diagram: it follows clean architecture principles, with the domain at the center. Everything starts with the domain.

When you think this way—where every part of your system is a piece of the domain that you can move around, tweak, or replace as needed—you’re free to make choices about the topology. Whether you go with a single deployable or a distributed system doesn’t matter much. With clean architecture in the middle, any changes you make are isolated to the infrastructure layer, so the decision is easy to reverse if needed.

But let’s ask ourselves: why not get all the benefits of a distributed architecture if it’s all the same effort? Earlier, we saw that microservices have a lot more advantages, and the so-called disadvantages are often debatable. Constantly falling back on trade-offs can sometimes be an excuse to avoid pushing for the best solution.

So far we have these as guidelines

• Everything starts with the domain. It’s what gives you direction and keeps your focus clear.

• To design a pure domain, clean architecture is essential.

• Topology is less important because it’s reversible**.** So why not aim for microservices if they bring more advantages?

Let’s zoom in on design now, where everything really begins. Here’s a quote from Clean Architecture book:

There has been a lot of confusion about design and architecture over the years. What is design? What is architecture? What are the differences between the two?

One of the goals of this book is to cut through all that confusion and to define, once and for all, what design and architecture are. For starters, I’ll assert that there is no difference between them. None at all.

I can’t overstate how important this is, and it’s a mindset that should stay at the heart of your development process. (I’ll admit I’m bending the context of the quote a bit here—it’s mostly referring to what I’ve called the “middle layer” rather than the domain itself—but it still applies.)

So, what is design? I see it as the process of modeling the domain. It ranges from identifying broad bounded contexts to defining the specific value objects and entities within them. Let me introduce some DDD concepts at this point:

Bounded contexts

Bounded Context is a logical boundary where a particular part of the domain is modeled. Think of it as the biggest piece of the puzzle—broad and coarse-grained. Identifying these boundaries is crucial. Ideally, you’d map out your organization’s core domain and subdomains, then align them with Bounded Contexts wherever possible. These contexts are (or will eventually be) the solutions you put in place

From Implementing Domain-Driven Design:

It is a desirable goal to align Subdomains one-to-one with Bounded Contexts. Doing so expressly segregates domain models into well-defined areas of business by objective […]. In practice this is not always possible, but it can work in a greenfield effort.

I could go on for ages about Bounded Context -seriously just read the first 3 chapters of Implementing Domain-Driven Design:- but I will try to stick to what it matters in the context of software architecture. For starters the Bounded Context is suppose to be the boundary of a “microservice”.

The Software Architecture: The Hard Parts spend an entire chapter discussing about how coarse-grained a service should be. It gives you some techniques about “granularity integrators and disintegrators”. But what they don’t mention is that this exercise is really about identifying Bounded Contexts. And, surprise—this comes directly from understanding the domain. The answer comes from domain expertise. That might mean consulting a domain expert, or (better yet) becoming one yourself through careful investigation of the domain.

Now, sometimes you might need to dig even deeper and break things down further into smaller pieces. That’s when the book The Software Architecture: The Hard Parts comes in handy. But remember: knowing where you are in the decision-making process is key. Without framing the problem properly, you’ll end up stuck in trade-off analyses that go nowhere..

You could actually have it the other way around, deploying several bounded contexts at once. That’s a monolith. But guess what. If you’ve followed DDD patterns and properly identified your Bounded Contexts within the monolith, breaking them apart into individual services later should be straightforward. The only way to achieve that is if your monolith had clean architecture in it.

Aggregate roots

The other concept to be aware of is the aggregate root. Loosely speaking they are entities. Strictly speaking, you could have several entities forming an aggregate roots (hence the term aggregate). Aggregate Roots define the transactional boundary: a transaction should only ever affect one aggregate, and that’s it.

Let me bring this excerpt from the The Software Architecture: The Hard Parts

“Well,” said Austen, “we are struggling with how many services to create for registering customers and maintaining customer-related information. You see, there are four main pieces of data we are dealing with here: profile info, credit card info, password info, and purchased product info.” [..] “There’s a single customer registration API to the backend, so if we separate services [..] would require a distributed transaction”.[..] “we wouldn’t be able to synchronize all of the data together as one atomic unit of work”.

“That’s not an option” said Parker. “All of the customer information is either saved in the database of it’s not. Let me put it another way. We absolutely cannot have the situation where we have a customer record without a corresponding credit card or password record. Ever.”

What’s happening here is a misdiagnose of the problem. This chapter is all about “transactional sagas,” but the issue isn’t about architecture—it’s a design problem! And that’s what happens when you neglect the domain and don’t make it your focus.

They are discussing a transactional boundary, which, you guessed it, is what an aggregate root defines. Failing to see that will bring you to some undesirable places like having to deal with distributed atomic transactions, which an aggregate root is explicitly designed to prevent. That’s why it’s so critical to get these boundaries right from the start.

In this case, the customer aggregate root should be designed alongside the related credit card or password records (as strange as it sounds…). But hey, that’s what the domain needs, those are the business rules! Now, if I were in this specific situation, I’d probably challenge the necessity of having a transactional boundary between these—there’s such a thing as common sense, right? I’d want a good explanation as the customer cannot exist without credit card information…).

Considering a trade-off around distributed transactions is a major red flag. sure, the book The Software Architecture: The Hard Parts book doesn’t give high ratings to distributed, atomic transactional sagas, but I think a warning was missing. A well-thought-out design will generally prevent you from running into these overly complex, uncomfortable problems. The domain is always more important than any architectural decision, tech solution, or topology. So, start by solving the problem at the domain level first.

Does it mean that you will never have to deal with distributed transactions? You might, for whatever reason: you are being forced, coerced, bribed or blackmailed. Also sometimes, within a single aggregate root, you might need to do something a little out of the ordinary. But as long as you understand you’re going way beyond the ideal design, that’s when you can make a more informed decision.

There’s another key rule when it comes to aggregate roots, and it affects your architecture. From Implementing Domain-Driven Design:

Rule: Use Eventual Consistency Outside the Boundary

Oh my this is from 2013 and The Software Architecture: The Hard Parts is from 2021. Looks like the former was a little but advanced to their time.

You can always bend the rules if you’re fully aware of it. In essence, it ensures that within a single aggregate root, you’ll always maintain a strong transactional boundary. But if you’re working with workflows that affect multiple aggregates, that’s where you’ll run into eventual consistency. This is especially important when it comes to topology because it guides you toward asynchronous communication between services.

And my guideline is that you should favor asynchronous communication. Let me show this diagram from Building Microservices (2nd Edition)

All right, I didn’t remember this exactly as it was, but here’s the idea: among different types of communication, non-blocking is the one I prefer. Why? Well, the term “non-blocking” is key—it means the calling service isn’t held up, so there’s less coupling between services. Of the non-blocking types, “common data” is the one that often breaks bounded contexts (you still might see this in migration scenarios though, so no shame in that). That leaves us with queue-based communication, which can either be request-response or event-driven. Request-response, creates more coupling because the calling service has to know more about the called service.

Event-driven communication is the one that keeps things loose. It’s all about “fire and forget.” Whether the services consuming the event are up or down doesn’t matter to the service triggering the event. This is especially important when you’re modeling the event—yes, modeling! Ideally, the event shouldn’t be influenced by the consumers, though, of course, there are trade-offs in this as well.

The key takeaway is that event-driven communication is the least coupled. It’s a great way to maintain eventual consistency—your system will eventually be consistent once the consuming service processes the event and finishes its part of the workflow.

Eventual consistency wouldn’t be possible without another important concept from Domain-Driven Design: domain events. Here’s another quote from Implementing Domain-Driven Design:

A domain event is a full-fledged part of the domain model, a representation of something that happened in the domain.

Well, that’s actually quoting the blue book. Domain Events is the information that should be found inside the messages. They also need to be modelled. Domain events always happen within a specific bounded context (as we’ve been talking about), and the services generating them care little of other services (the ones that implement other bounded contexts) need to do any action as consequence or not.

If you got the pieces right (the bounded contexts and the aggregate roots), eventual consistency will give you the least coupled system. That’s important as a coupled system will have none of the benefits of the distributed architecture plus the disadvantage of the complexity.

To wrap up, if you want to get all the advantages of distributed architecture, it really boils down to a solid domain analysis and design. It all starts there. So, by getting the domain right and modeling it well, you’ll naturally arrive at a system that takes advantage of asynchronous communication, eventual consistency, and low coupling.

Rich domain

The final guideline in the "code" section is probably the most important one. It’s about properly designing and modeling the domain. But here's the thing: this isn't just a Domain-Driven Design (DDD) concept. It's actually a universal truth in software development. Take this from A Philosophy of Software Design:

Chapter 4: Modules should be deep.

Or from Building Microservices (2nd Edition):

Microservices embrace the concept of information hiding. Information hiding means hiding as much information as possible inside a component and exposing as little as possible via external interfaces.

They all speak about the same, about the fight for the best design, one that hides complexity and is open only to be used in a very specific way (the simplest way possible - that doesn’t mean it will be simple, just simpler than any other way). In DDD terms that’s called a rich domain, the opposite being an anemic domain.

It’s fun to see that the former book (the philosophy one) never mentions domain yet it has the best defense for a rich domain that I’ve seen.

This is a piece of advice that I see it’s commonly overlooked. I have seen so many code by DDD practitioners that is just exposing a CRUD interface of all the entities, delegating all the logic to the client using the system. For that, you’d better have an Excel spreadsheet.

That’s why the “rich domain” principle is so crucial—it helps you create the right abstractions and the best designs. The way to think about is “what do I want as a result?” From there, you can start designing the interface, the modules, the classes, and the expected results. This matches perfectly with Test-Driven Development (TDD), where you design the test first, and then implement. TDD will guide you to create deeper modules that hide complexity.

So summing up until now we have all of those guidelines:

• Everything starts with the domain - it gives you direction.

• To model or design a pure domain, clean architecture is a must.

• Topology is easy to change, so it’s less important (why not go for microservices when they clearly have more advantages than monolithic topologies?).

• Design bounded contexts that mark the boundaries of each service.

• Make sure aggregate roots are properly designed.

  • Avoid distributed atomic transactions.

• Design Domain Events

  • Favor Event Driven communication and eventual consistency.

• Go rich in the domain, hide complexity and offer the domain to be executed in the specific way you want.

  • TDD will help you with that.

The organization

Now, putting all of that into practice is tough, especially the first time around. That’s why another must-have guideline is to favor agile approaches to software development. All of these approaches are the result of the "DevOps" revolution—a direct reaction against the waterfall approach. Without this mindset in your organization, implementing all of the principles we’ve discussed so far will be challenging.

With an iterative approach, you’ll have the chance to improve your design with every cycle. Not to mention that requirements tend to change over time, and this is another advantage of clean architecture. Changes to the domain are easy to make, and everything else falls into place almost automatically, meaning a minimal time to market.

You might be wondering why I’m focusing on the organization. After all, I’m discussing software architecture and the process of software engineering. But the truth is, you can’t engineer software if your organization doesn’t provide the right environment, tools, and space for it. That’s why this is such an important part of the whole software engineering process.

At this level, you’ll likely have some leverage to implement key practices across the organization. One of the first steps should be pushing for domain-based teams. Take a look at this figure from Building Microservices (2nd Edition):

Which approach do you think will require the least coordination to make a domain-related change—the one on the left or the one on the right? Of course, it’s the right one! Will domain-related changes be more common than technical ones? I’m not entirely sure -just quite-, but I’d argue they’re probably more important to implement. As I’ve said time and time again, the domain is at the center.

And don’t forget about Conway’s Law: the architecture reflects the organization. So you should make use of the reverse Law: by organizing teams around domains, the resulting system will naturally reflect that structure. The most dysfunctional companies I’ve seen are the ones that follow the model on the left (like the example company in The Software Architecture: The Hard Parts). According to Conway’s Law, that leads to a distributed monolith—a big, messy system that’s hard to manage. (You can also read Building Microservices (2nd Edition) for more on “enabling teams” as an alternative.)

So, if you have domain-based teams, how do you get the domain experts? IT needs to work closely with the rest of the organization, including the business side and the stakeholders. Ideally, IT should be embedded within each part of the organization, which, in turn, should also be partitioned by domains, bounded contexts, and so on. This kind of structure usually develops organically. You’ll get a solid understanding of this approach from Project Phoenix book, another must-read if you want to embrace the DevOps mindset.

And lastly, there’s culture. I’ve used this quote before in another blog post, but it’s worth repeating: “Culture eats strategy for breakfast.” You can’t accomplish anything without the right culture. In Accelerate, they discuss different organizational types according to the "Westrum" model, and they even quantify how harmful it is to be in a "Power-oriented" organization (you could easily translate that to lost money).

This, in my opinion, is the most important principle of them all. To sum it up, I’ll go with this stament: "Don’t be a jerk." People make mistakes, they learn from them, they grow professionally, and they have both good days and bad. The key is to get the best out of them—not the worst.

Conclusion

This is the list we made so far:

• Everything starts with the domain, it’s what gives you direction

• To model or design a pure domain, clean architecture is a must.

• Topology is easily reversible therefore less important (why not go for microservices then if it has obviously way more advantages than monolithical topologies?)

• Bounded Contexts tell you broadly each service boundary.

• Make sure aggregate roots are properly designed.

  • Avoid distributed atomic transactions.

• Design Domain Events

  • Favor Event Driven communication and eventual consistency.

• Go rich in the design, hide complexity and offer the domain to be executed in the specific way you want. (TDD will help you with that.)

• Embrace agile mindsets

• Domain based teams (Take into account Conway’s law)

• IT embedded with the rest of the company

• Actively promote a generative (performance-oriented) Westrum culture. (And, of course, never be a jerk.)

These principles have always worked for me, and they’ve produced great results. You don’t have to take my word for it—the book Accelerate backs it up with real data. Companies that follow these practices are more likely to excel in all the categories discussed here: https://kodus.io/en/dora-accelerate-state-of-devops/ . I am adding pieces of my own, but everything related to the company it’s included, and everything else related to architecture also but more broadly without going into much detail.

The book The Software Architecture: The Hard Parts might say I am an evangelist but that’s simply been my experience. Once somebody teaches me something else that works better I will adapt it. But it’s not going to be architectural knowledge based on DDD and yet it ignores its principles and rules)

The sources for all of this are quite diverse, yet they have synergies and build on each other. Here’s the complete list of sources I strongly recommend you buy (or convince your company to buy) and read:

• Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans, the blue book, the one that started it all

• Implementing Domain-Driven Design by Vaughn Vernon, the red book. If you have trouble keeping awake you may try the “distilled” version. But it’s worth trying the fatty one.

• Clean Architecture: A Craftsman's Guide to Software Structure and Design (Robert C. Martin Series)You can read it all for free as a series of blog posts.

• Building Microservices: Designing Fine-Grained Systems by Sam Newman. Make sure it’s the second edition. This is probably my favorite.

• The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win by Gene Kim, Kevin Behr and George Spafford (I though it was only Gene Kim).

• Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations by Nicole Forsgren, Jez Humble and Gene Kim (again!)

And a couple of extra book to complete the DevOps mindset but I didn’t mention in this blog post.

• Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (Addison-Wesley Signature Series (Fowler)) by Jez Humble (have you seen him before?) and David Farley. There’s some stuff that can feel outdated but the principles stay strong.

• Domain-Driven Design in PHP: A highly practical guide. by Carlos buenosvinos, Christian Soronellas, Keyvan Akbary. It’s languge specific but might help you greatly to put all the pieces together.

So maybe this blog post wasn’t enough to convince you, but after reading all these books, you should be fully convinced. There is an approach that works—a better approach than others—that gives you concrete guidelines and keeps you away from sterile trade-off debates, bringing you back to the trade-off debates that matter.