a statement or proposition which is regarded as being established, accepted, or self-evidently true.
Mathematicians create theories based on axioms, assumptions for things indisputably true. Software architects build axioms as well, but the software world is, well, softer than mathematics: fundamental things continue to change at a rapid pace in the software world.
The software development ecosystem exists in a constant state of dynamic equilibrium: while it exists in a balanced state at any given point in time, it exhibits dynamic behavior over the long term. A great modern example of the nature of this ecosystem follows the ascension of containerization and the attendant changes wrought: tools like Kubernetes didn’t exist a decade ago, yet now entire software conferences exist to service its users. The software ecosystem changes fractally: one small change causes another small change; when repeated hundreds of time, it generates a new ecosystem.
Architects have an important responsibility to continue to question assumptions and axioms left over from previous eras. Many of the books about software architecture were written in an era that only barely resembles the current world. In fact, the authors believe that we must question fundamental axioms on a regular basis, in light of improved engineering practices, operational ecosystems, software development processes—everything that makes up the messy, dynamic equilibrium where architects and developers work each day.
Careful observers of software architecture over time witnessed a slow evolution of capabilities. Starting with the engineer practices of eXtreme Programming, continuing with Continuous Delivery, the DevOps revolution, microservices, containerization, and now cloud-based resources, all of these innovations lead to new capabilities and tradeoffs. As a good illustration of this perspective shift, for many years, the tongue-in-cheek definition of software architecture was “the stuff that’s hard to change later”. Then, the microservices architecture style appeared, where change is a first-class design consideration.
Each new era requires new practices, tools, measurements, patterns, and a host of other changes. This book looks at software architecture in modern light, taking into account all the innovations from the last decade, along with some new metrics and measures suited to the new structures and perspectives now available.
One possible subtitle of our book was “An Engineering Approach”. Developers have long wished to change software development from a craft, which skilled artisans can create one-off works, to an engineering discipline, which implies repeatability, rigor, and effective analysis. While software engineering still lags behind others by many orders of magnitude (to be fair, software is a very young discipline compared to most other types of engineering), architects have made huge improvements, which we reflect. In particular, modern agile engineering practices have allowed great strides in the types of systems architects design and the attendant engineering practices that enable them.
We also address the critically important issue of tradeoff analysis. Architects often appear grumpy because the binary clarify of developers melts away. As a software developer, it’s easy to become enamored with, enthusiastic about, and even evangelical about a particular bit of technology or approach. However, architects must always soberly assess the good, bad, and ugly of every choice, and virtually nothing in the real world offers convenient binary choices—everything is a tradeoff. Given this pragmatic perspective, we strive eliminate value judgments about technology and focus on analyzing the real tradeoffs to equip our readers with an analytic eye towards technology choices.
This book won’t make someone a software architecture overnight—it’s a nuanced field with many facets. We want to provide existing and burgeoning architects a good modern overview of software architecture and its many aspects, from structure to soft skills. While this book covers well known patterns, we take a new approach, leaning on modern lessons learned, tools, engineering practices, and other input to build a modern book on software architecture.
The following typographical conventions are used in this book:
Indicates new terms, URLs, email addresses, filenames, and file extensions.
Used for program listings, as well as within paragraphs to refer to program elements such as variable or function names, databases, data types, environment variables, statements, and keywords.
Constant width bold
Shows commands or other text that should be typed literally by the user.
Constant width italic
Shows text that should be replaced with user-supplied values or by values determined by context.
This element signifies a tip or suggestion.
This element signifies a general note.
This element indicates a warning or caution.
Supplemental material (code examples, exercises, etc.) is available for download at https://github.com/oreillymedia/title_title.
If you have a technical question or a problem using the code examples, please send email to email@example.com.
This book is here to help you get your job done. In general, if example code is offered with this book, you may use it in your programs and documentation. You do not need to contact us for permission unless you’re reproducing a significant portion of the code. For example, writing a program that uses several chunks of code from this book does not require permission. Selling or distributing examples from O’Reilly books does require permission. Answering a question by citing this book and quoting example code does not require permission. Incorporating a significant amount of example code from this book into your product’s documentation does require permission.
We appreciate, but generally do not require, attribution. An attribution usually includes the title, author, publisher, and ISBN. For example: “Fundamentals of Software Architecture by Some Author (O’Reilly). Copyright 2012 Neal Ford, Mark Richards, 978-1-492-04345-4.”
If you feel your use of code examples falls outside fair use or the permission given above, feel free to contact us at firstname.lastname@example.org.
For more than 40 years, O’Reilly Media has provided technology and business training, knowledge, and insight to help companies succeed.
Our unique network of experts and innovators share their knowledge and expertise through books, articles, conferences, and our online learning platform. O’Reilly’s online learning platform gives you on-demand access to live training courses, in-depth learning paths, interactive coding environments, and a vast collection of text and video from O’Reilly and 200+ other publishers. For more information, please visit http://oreilly.com.
Please address comments and questions concerning this book to the publisher:
We have a web page for this book, where we list errata, examples, and any additional information. You can access this page at https://oreil.ly/fundamentals-of-software-architecture.
Email email@example.com to comment or ask technical questions about this book.
For more information about our books, courses, conferences, and news, see our website at http://www.oreilly.com.
Find us on Facebook: http://facebook.com/oreilly
Follow us on Twitter: http://twitter.com/oreillymedia
Watch us on YouTube: http://www.youtube.com/oreillymedia