Table of Contents (the real thing)
-
Because software architecture is hard, your brain will trick you into thinking you can’t learn it. Your brain’s thinking, ”Better to focus on more important things, like what to eat for lunch and whether pigs have wings.” The good news is that you CAN trick your brain into thinking software architecture is an important skill to learn, and in this chapter we’re going to show you just how to do that.
-
Software architecture is fundamental to the success of your system. This chapter demystifies software architecture. You’ll gain an understanding of architectural dimensions and the differences between architecture and design. Why is this important? Because understanding and applying architectural practices helps you build more effective and correct software systems—systems that not only function better, but also meet the needs and concerns of the business and continue to operate as your business and technical environments undergo constant change. So, without further delay, let’s get started.
-
What does your architecture need to support? Architectural characteristics (the capabilities of an architecture) are the fundamental building blocks of any system. Without them, you cannot make architectural decisions, select an architectural style, or in many cases even create a logical architecture. In this chapter you’ll learn how to define some of the more common characteristics (like scalability, reliability, and testability), how they influence a software architecture, how they help you make architectural decisions, and how to identify which ones are important for your particular situation. Ready to add some capabilities to your software architecture?
-
What happens when there are no “best practices”? The nice thing about best practices is that they’re relatively risk-free ways to achieve certain goals. They’re called “best” (not “better” or “good”) for a reason—you know they work, so why not just use them? But one thing you’ll quickly learn about software architecture is that it has no best practices. You’ll have to analyze every situation carefully to make a decision, and you’ll need to communicate not just the “what” of the decision, but the “why.”
So, how do you navigate this new frontier? Fortunately, you have the laws of software architecture to guide you. This chapter shows you how to analyze trade-offs as you make decisions. We’ll also show you how to create architectural decision records to capture the “hows” and “whys” of decisions. By the end of this chapter, you’ll have the tools to navigate the uncertain territory that is software architecture.
-
Ready to start creating an architecture? It’s not as easy as it sounds—and if you don’t do it correctly, your software system could come crumbling to the ground, just like a poorly designed skyscraper or bridge.
In this chapter we’ll show you several approaches for identifying and creating logical components, the functional building blocks of a system that describe how its pieces all fit together. Using the techniques described in this chapter will help you to create a solid architecture—a foundation upon which you can build a successful software system.
Put on your hard hat and gloves, get your tools ready, and let’s get started.
-
There are lots of different architectural styles out there. Each one exists for a reason and has its own philosophy about how and when it should be used. Understanding a style’s philosophy will help you judge whether it’s the right one for your domain. This chapter gives you a framework for the different kinds of architectural styles (which we’ll be diving into for the remainder of this book), to help you make sense of these and all the other architectural styles you’ll encounter as a software architect.
Let’s fill in that final piece of the puzzle, shall we?
-
What if your problem is simple and time is of the essence? Should you even bother with architecture? It depends on how long you want to keep what you build. If it’s disposable, throw caution to the wind. If not, then choose the simplest architecture that still provides some measurable organization and benefit, without imposing many constraints on speed of delivery. The layered architecture has become that architecture because it’s easy to understand and implement, leveraging design patterns developers already know. Let’s peel back the layers of this architecture.
-
There’s more than one way to build a monolith. So far, you’ve encountered the layered architecture, which aligns things technically. You can go a long way with a layered monolith, but when changes begin to involve lots of communication and coordination between different teams, you might need a little more horsepower under the hood—and perhaps even a different architectural style.
This chapter looks at the modular monolith architectural style, which divides applications up by business concerns as opposed to technical concerns. You’ll learn what this means, what to look out for, and all the trade-offs associated with this style. Let’s take the modular monolith for a spin, shall we?
-
You can craft custom experiences, one capability at a time. Some architecture styles are particularly well suited for some capabilities, and the microkernel architecture is the world champion at customization. But it’s also useful for a bewildering range of applications. Once you understand this architectural style, you’ll start seeing it everywhere!
Let’s dig into an architecture that lets your users have it their way.
-
Ready to extend your journey into software architecture? In this chapter, you’re the software architect. You’ll be determining architectural characteristics, building a logical architecture, making architectural decisions, and deciding whether to use a layered, modular, or microkernel architecture. The exercises in this chapter will give you an end-to-end view of what a software architect does and show you how much you’ve learned. Get ready to create an architecture for a startup company building a travel integration convenience site. Bon voyage—we hope you have a good trip building your architecture.
-
How do you make an architecture easier to change? Business is changing faster than ever, and software architectures need to keep up. In this chapter you’ll learn how to create a flexible architecture that can change as your business changes, scale as your business grows, and remain operational even when system failures occur. Intrigued? We hope so, because in this chapter we’re going to show you microservices—an architectural style that solves all of these problems and more. Let’s get started on our journey through microservices, bit by bit.
-
What if your architecture could do lots of things at the same time? As businesses grow and become more successful, they need to be able to handle more and more users, without slowing down or crashing systems. In this chapter, you’ll learn how to design high-performance systems that can scale as a business grows. Get ready for event-driven architecture, a highly popular distributed architecture style. It’s very fast, highly scalable, and easy to extend—but it’s also quite complex. You’ll be learning about lots of new concepts in this chapter, including things like events, messages, and asynchronous communication, so you can create an architectural that can do many things at once. Fasten your seatbelt, and let’s go on an asynchronous adventure through event-driven architecture.
-
Ready to test your skills in creating a distributed architecture? In this chapter, you’re the software architect. You’ll be determining architectural characteristics, building a logical architecture, making architectural decisions, and deciding whether to use microservices or event-driven architecture. The exercises in this chapter will give you an end-to-end view of what a software architect does and show you how much you’ve learned. Get ready to create an architecture for a student standardized test–taking system called Make the Grade. Good luck—we hope you get an A on your architecture!
-
There’s a lot more to be said about software architecture. We promise you’re done with this book. But reading this book is just the first step in your journey to thinking architecturally, and we couldn’t in good conscience let you go without a little more preparation. So, we’ve gathered a few additional juicy bits into this appendix. Each of the topics that follow deserves as much attention as the other topics we’ve covered. However, our goal here is just to give you a high-level idea of what they’re all about. And yes, this really is the end of the book. Except for the index, of course—it’s a real page-turner!
Get Head First Software Architecture now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
