Design It!¶
Metadata¶
- Author: [[Keeling, Michael;]]
Highlights¶
This book is divided into three parts. Parts I and II are designed to be read start to finish. Part III is designed for easy reference. — location: 265 ^ref-36242
There are four design mindsets: understand, explore, make, and evaluate. — location: 273 ^ref-41842
Software architecture design is a human-centered design discipline. Everyone with a stake in the software can help you understand what is expected of it. Software architects work with product managers, project managers, and other stakeholders to define business goals and requirements for the software to be built. — location: 317 ^ref-47997
Architects partition (a fancy word for divide into pieces) the software system so they can develop a strategy for achieving quality attributes and other system requirements. For example, you might assign functional responsibilities by designing one component to register users and another to identify pictures of cats. Or you could assign different teams to develop different modules. Or you might split things that read data from things that write data so the software system will be more reliable, available, and scalable. — location: 331 ^ref-52446
Smaller things are easier to reason about, easier to test, and easier to design. Of course, since you broke the system into pieces, you’ll also have to make sure everything can come back together again. — location: 335 ^ref-64066
Software design is a constant struggle to find the right balance between the things you want and the reality you must accept. This means you must think about and make trade-offs. — location: 344 ^ref-26041
Technical debt is the gap between your software system’s current design and the design you need it to have so you can continue to deliver value. — location: 355 ^ref-23011
All software has technical debt. Technical debt is an inevitable byproduct of success. The best software development teams use technical debt strategically to ship faster and regularly pay debt down so they can continue shipping value over time. — location: 356 ^ref-60283
Architecture can promote other properties too. For example, the right architecture for the job will let you ship on time, on budget, and without requiring too much overtime. — location: 373 ^ref-28749
Software Architecture in Practice [BCK12] defines these three types as module, component and connector (C&C for short), and allocation. To create a structure, combine elements and relations of the same type. — location: 381 ^ref-24042
Technically a component is a different concept from a module. A module refers to a design time element whereas a component is a runtime idea. — location: 408 ^ref-62602
Anytime you want to describe a generic building block of an architecture instead of using component or module, use the word element. — location: 411 ^ref-26859
A quality attribute is any externally visible characteristic by which stakeholders judge a software system’s goodness. Some examples include scalability, availability, maintainability, and testability. You experience quality attributes when you interact with the software. — location: 435 ^ref-19848
Quality attributes make software unique. The circumstances of every system are different—different team, different budget, different market conditions, even different technology trends. As a result, no two architectures will ever be the same even if the feature sets are identical. — location: 440 ^ref-22736
For every software system you build, no matter your role, briefly describe the software system and what you learned during your time developing it. — location: 458 ^ref-15654
When designing architecture, you’ll consider not only the features but also costs, constraints, schedules, risk, the ability of the team to deliver, and most importantly quality attributes—things like scalability, availability, performance, and maintainability. — location: 486 ^ref-32408
The important stuff is nearly always what we think will be difficult to change without significantly increasing complexity. — location: 490 ^ref-2788
Your software should respond to change like water, by bending around obstacles with ease. If software is like water, able to take any shape, then software architecture is the container that holds it. That container can be rigid like a box or flexible like a plastic bag. It can be thick and heavy or lightweight. Without an architecture, software, like water, follows the path of least resistance and sprawls uncontrollably. A software system’s architecture provides the structure within which change is possible. — location: 494 ^ref-46618
Design thinking is less a process and more a way of thinking about problems and solutions from the perspective of the people affected by them. — location: 534 ^ref-62859
Here are the four principles of design: 1. Human rule. All design is social in nature. 2. Ambiguity rule. Preserve ambiguity. 3. Redesign rule. All design is redesign. 4. Tangibility rule. Make ideas tangible to facilitate communication. — location: 538 ^ref-11254
Empathizing with the humans who directly and indirectly interact with the architecture makes us a better designer, communicator, and leader. — location: 554 ^ref-27543
One of the least effective ways to design software architecture is to ignore the software systems that came before us. — location: 575 ^ref-61716
There are many ways to make architecture tangible. Draw it. Make it come alive in the code you write. Build prototypes that let people experience structures and quality attributes. Create simple models that show how some part of the architecture works. Create relatable metaphors. Act out parts of the control flow of the system. — location: 579 ^ref-25371
There are four design mindsets: understand, explore, make, and evaluate. Each design mindset comes with a set of practices. — location: 589 ^ref-10724
The most common ways we make architecture real is by creating models. Making goes way beyond box and line diagrams. You can make the architecture real by building prototypes, writing documents, crunching numbers, and a variety of other approaches. — location: 608 ^ref-31349
A software system is never finished; it is only released. — location: 644 ^ref-40469