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

In lesson 148 I talked about what Neal Ford and I coined as the 10th Fallacy of Distributed Computing: "Compensating updates always work”, and the issues associated with compensating updates (no, they DON’T always work). In this lesson I expand on that lesson to talk about some of the ways to work around compensating update failures while at the same time providing transactional isolation within a distributed transaction.   Reference Links: Compensating Updates: https://www.developertoarchitect.com/lessons/lesson148.html Software Architecture Monday: https://bit.ly/3d ..read more

In lesson 165 I spoke about event-driven architecture and when you should (and shouldn’t) use it. In this lesson I’ll take a deeper dive into EDA by discussing the differences between events and messages (yes, they are different things!). Then I’ll show when you might want to use messages within an event-driven architecture. Reference Links: Event-Driven Architecture: https://www.developertoarchitect.com/lessons/lesson165.html Software Architecture Monday: https://bit.ly/3dadEe3 Fundamentals of Software Architecture: https://amzn.to/3rgFLjY Software Architecture: The Hard Parts ..read more