More on this book
Community
Kindle Notes & Highlights
Read between
April 13 - May 12, 2019
Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change. —Grady Booch
If you think good architecture is expensive, try bad architecture. —Brian Foote and Joseph Yoder
The goal of software architecture is to minimize the human resources required to build and maintain the required system. The measure of design quality is simply the measure of the effort required to meet the needs of the customer. If that effort is low, and stays low throughout the lifetime of the system, the design is good. If that effort grows with each new release, the design is bad. It’s as simple as that.
Goal and measure of a design
Structured programming is discipline imposed upon direct transfer of control. • Object-oriented programming is discipline imposed upon indirect transfer of control. • Functional programming is discipline imposed upon variable assignment. Each of these three paradigms has taken something away from us. Each restricts some aspect of the way we write code. None of them has added to our power or our capabilities. What we have learned over the last half-century is what not to do.
Programming Paradigms
Thus the final version of the SRP is: A module should be responsible to one, and only one, actor.
Single responsibility principal
The Open-Closed Principle (OCP) was coined in 1988 by Bertrand Meyer.1 It says: A software artifact should be open for extension but closed for modification.
The open-closed principle
Gather together those things that change at the same times and for the same reasons. Separate those things that change at different times or for different reasons.
How can we measure the stability of a component? One way is to count the number of dependencies that enter and leave that component. These counts will allow us to calculate the positional stability of the component. • Fan-in: Incoming dependencies. This metric identifies the number of classes outside this component that depend on classes within the component. • Fan-out: Outgoing dependencies. This metric identifies the number of classes inside this component that depend on classes outside the component. • I: Instability: I = Fan-out / (Fan-in + Fan-out). This metric has the range [0, 1]. I = 0
...more
Stability Metrics
Software was invented because we needed a way to quickly and easily change the behavior of machines. But that flexibility depends critically on the shape of the system, the arrangement of its components, and the way those components are interconnected.
Purpose of software
A good architecture will allow a system to be born as a monolith, deployed in a single file, but then to grow into a set of independently deployable units, and then all the way to independent services and/or micro-services. Later, as things change, it should allow for reversing that progression and sliding all the way back down into a monolith.
Born Monolith to evolve service
the goal of an architect is to minimize the human resources required to build and maintain the required system.
Goal of architect
Which kinds of decisions are premature? Decisions that have nothing to do with the business requirements—the use cases—of the system. These include decisions about frameworks, databases, web servers, utility libraries, dependency injection, and the like. A good system architecture is one in which decisions like these are rendered ancillary and deferrable. A good system architecture does not depend on those decisions. A good system architecture allows those decisions to be made at the latest possible moment, without significant impact.
Premature Architecture decision
The fact that we did not have a database running for 18 months of development meant that, for 18 months, we did not have schema issues, query issues, database server issues, password issues, connection time issues, and all the other nasty issues that raise their ugly heads when you fire up a database. It also meant that all our tests ran fast, because there was no database to slow them down.
Deferred decision about database
Boundaries are drawn where there is an axis of change. The components on one side of the boundary change at different rates, and for different reasons, than the components on the other side of the boundary. GUIs change at different times and at different rates than business rules, so there should be a boundary between them. Business rules change at different times and for different reasons than dependency injection frameworks, so there should be a boundary between them.
Boundaries Between components
Recall that policies are grouped into components based on the way that they change. Policies that change for the same reasons and at the same times are grouped together by the SRP and CCP. Higher-level policies—those that are farthest from the inputs and outputs—tend to change less frequently, and for more important reasons, than lower-level policies. Lower-level policies—those that are closest to the inputs and outputs—tend to change frequently, and with more urgency, but for less important reasons.
Policies changes
good software architecture allows decisions about frameworks, databases, web servers, and other environmental issues and tools to be deferred and delayed. Frameworks are options to be left open. A good architecture makes it unnecessary to decide on Rails, or Spring, or Hibernate, or Tomcat, or MySQL, until much later in the project. A good architecture makes it easy to change your mind about those decisions, too. A good architecture emphasizes the use cases and decouples them from peripheral concerns.
Writing working code that doesn’t block future code is a non-trivial skillset. It takes years to master.
Future code
4-TEL archaeology project, 345, 347–348 replacing disks, 280–281 Rational (company), 371, 372 RDBMS (relational database management systems), 279
