Most people are familiar with the famous “8 Fallacies of Distributed Computing”, which I talked about in Lesson 18. A fallacy is something we believe to be true, but is in fact not true. Neal Ford and I have been working hard to identify the next 8 fallacies. In Lesson 147 I published Fallacy #9 (versioning is easy), and in Lesson 148 I published Fallacy #10 (compensating updates always work). In this lesson I’ll introduce Fallacy #11 of distributed computing: observability is optional. In this lesson I’ll demonstrate what observability is in distributed architecture and why it is mandatory f ..read more

How can we create an architecture that can accomodate constant state  of change and uncertaint? The answer is Residualiy Theory. In this lesson I describe what residulaity theory is about and show how it can address the uncertainty and change we expierience every day in complicated systems.  Residuality Theory: https://leanpub.com/residuality Head First Software Architecture: https://amzn.to/3VNFI0o Software Architecture Monday: https://bit.ly/3dadEe3 Fundamentals of Software Architecture: https://amzn.to/3rgFLjY Software Architecture: The Hard Parts: https://amz ..read more

Architecture Katas are a great way to practice and learn about software architecture. They start with a simple problem statement, and teams (or individuals) create a software architecture based on that problem. In this lesson I walk through what an architecture kata is, why the exercise is so valuable, and then describe the five main activities involved with running your own architecture kata.  Architecture Katas: https://fundamentalsofsoftwarearchitecture.com/katas/ Kata Resources: https://www.developertoarchitect.com/resources.html Head First Software Architecture: https ..read more

I’m excited to announce the launch of our latest book, Head First Software Architecture (O’Reilly, 2024). In this lesson I talk about how this book differs from our prior book, the Fundamentals of Software Architecture (O’Reilly, 2020), and provide you with a sneak peek into the book by briefly showing you what’s in each chapter. Happy reading!   Reference Links: Head First Software Architecture: https://www.amazon.com/Head-First-Software-Architecture-Architectural/dp/1098134354/ Software Architecture Monday: https://bit.ly/3dadEe3 Fundamentals of Software Architectur ..read more

I lessons 179 and 180 I talked about "domain to architecture isomorphism” and showed how it is used to help choose the right architecture for your problem domain. In this lesson I show several examples of how to apply domain to architecture isomorphism, concluding this 3-part lesson.     Reference Links: Domain to Architecture Isomorphism Part 1: https://www.developertoarchitect.com/lessons/lesson179.html Domain to Architecture Isomorphism Part 2: https://www.developertoarchitect.com/lessons/lesson180.html Software Architecture Monday: https://bit.ly/3dadEe3 Fundament ..read more

Feasibility is an often overlooked architectural characteristic. It identifies how feasible your solution is based on time, budget, and skillset constraints. It is also linked to requirements handed down from product owners or business stakeholders. Many times, what architects and development teams receive are not requirements, but rather solutions. Through some story telling and real-world examples, I show in this lesson how to identify real requirements, particularly when a requirement doesn’t seem feasible.   Reference Links: Software Architecture Monday: https://bit.ly/3dadEe3 F ..read more

I lesson 179 (part one) I defined what "domain to architecture isomorphism" is and how it is used to help choose the right architecture for your problem domain. In this lesson (part two) I describe the “shape” of 8 common architectural styles: Layered, Modular Monolith, Microkernel, Microservices, Service-Based, Service-Oriented, Event-Driven, and Space-Based. By understanding the shape of each architectural style, you can then match it to the shape of the problem you are trying to solve.   Reference Links: Domain to Architecture Isomorphism Part 1: https://www.developertoarchitect ..read more

Domain to architecture isomorphism is a way of determining how close the shape of the architecture matches the shape of the problem domain. Every architecture has a shape, as does every problem domain. In this lesson I show what is meant by the “shape of the problem domain”, and how things can go terribly wrong when the architectural style you selected doesn’t match the problem domain. I then show how you can use domain to architecture isomorphism to address this common problem.  Reference Links: Apache Kafka vs Standard Messaging: https://www.developertoarchitect.com/lessons/lesson ..read more

How do you increase the overall throughput and capacity of a messaging or eventing system? In this lesson I talk about a pattern using standard messaging (RabbitMQ, ActiveMQ, Solace, Memphis, and so on) that can significantly increase your messaging throughput, matching that of Apache Kafka. Intrigued? Then this video is for you!      Reference Links: Apache Kafka vs Standard Messaging: https://www.developertoarchitect.com/lessons/lesson2.html Software Architecture Monday: https://bit.ly/3dadEe3 Fundamentals of Software Architecture: https://amzn.to/3rgFLjY Softw ..read more

Logical components in software architecture are the building blocks of the system—in other words, things the system does. Logical components combine to form what is called a logical architecture, describing the overall structure of the system and show how the components interact with each other. In this lesson I define what a logical component of an architecture is and how it relates to the structure of the source code (and visa-versa).       Reference Links: Software Architecture Monday: https://bit.ly/3dadEe3 Fundamentals of Software Architecture: https://amzn.to/3r ..read more