Skip to content

Design It!


  • Author: [[Keeling, Michael;]]


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