More on this book
Community
Kindle Notes & Highlights
Read between
May 19 - June 11, 2019
A component should be as abstract as it is stable.
Some software entities do, in fact, fall within the Zone of Pain. An example would be a database schema. Database schemas are notoriously volatile, extremely concrete, and highly depended on.
Nonvolatile components are harmless in the (0, 0) zone since they are not likely to be changed. For that reason, it is only volatile software components that are problematic in the Zone of Pain.
• D3: Distance. D = |A+I–1| .
Statistical analysis of a design is also possible. We can calculate the mean and variance of all the D metrics for the components within a design.
First of all, a software architect is a programmer; and continues to be a programmer. Never fall for the lie that suggests that software architects pull back from code to focus on higher-level issues.
The strategy behind that facilitation is to leave as many options open as possible, for as long as possible.
Lazy preocupation strategy
the architecture of a system has very little bearing on whether that system works.
Good architecture makes the system easy to understand, easy to develop, easy to maintain, and easy to deploy. The ultimate goal is to minimize the lifetime cost of the system and to maximize programmer productivity.
A software system that is hard to develop is not likely to have a long and healthy lifetime.
As we described in an earlier chapter, software has two types of value: the value of its behavior and the value of its structure. The second of these is the greater of the two because it is this value that makes software soft. Software was invented because we needed a way to quickly and easily change the behavior of machines.
The way you keep software soft is to leave as many options open as possible, for as long as possible.
What are the options that we need to leave open? They are the details that don’t matter.
All software systems can be decomposed into two major elements: policy and details. The policy element embodies all the business rules and procedures. The policy...
This highlight has been truncated due to consecutive passage length restrictions.
The details are those things that are necessary to enable humans, other systems, and programmers to communicate with the policy, but that do not ...
This highlight has been truncated due to consecutive passage length restrictions.
The goal of the architect is to create a shape for the system that recognizes policy as the most essential element of the system while making the details irrelevant to that policy. This allows decisions about those details to be delayed and deferred.
If you can develop the high-level policy without committing to the details that surround it, you can delay and defer decisions about those details for a long time. And the longer you wait to make those decisions, the more information you have with which to make them properly.
A good architect maximizes the number of decisions not made.
Conway’s law says:
Any organization that designs a system will produce a design whose structure is a copy of the organization’s communication structure.
A good architecture helps the system to be immediately deployable after build.
The reality is that achieving this balance is pretty hard.
In short, the goals we must meet are indistinct and inconstant. Welcome to the real world.
Some principles of architecture are relatively inexpensive to implement and can help balance those concerns, even when you don’t have a clear picture of the targets you have to hit. Those principles help us partition our systems into well-isolated components that allow us to leave as many options open as possible, for as long as possible.
DECOUPLING LAYERS
validation of input fields is a business rule that is closely tied to the application itself. In contrast, the calculation of interest on an account and the counting of inventory are business rules that are more closely associated with the domain.
DECOUPLING USE CASES
DECOUPLING MODE
Remember, a good architecture leaves options open. The decoupling mode is one of those options.
INDEPENDENT DEVELOP-ABILITY
INDEPENDENT DEPLOYABILITY
DUPLICATION
Architects often fall into a trap—a trap that hinges on their fear of duplication.
there are different kinds of duplication. There is true duplication, in which every change to one instance necessitates the same change to every duplicate of that instance. Then there is false or accidental duplication. If two apparently duplicated sections of code evolve along different paths—if they change at different rates, and for different reasons—then they are not true duplicates.
DECOUPLING MODES (AGAIN)
I was adamant that anything we produced should not require people to download more than one jar file. I called this rule, “Download and Go.” This rule drove many of our decisions.
One of the first decisions was to write our own web server, specific to the needs of FitNesse. This might sound absurd. Even in 2001 there were plenty of open source web servers that we could have used. Yet writing our own turned out to be a really good decision because a bare-bones web server is a very simple piece of software to write and it allowed us to postpone any web framework decision until much
Many of us have been taught to believe that the database is inextricably connected to the business rules. Some of us have even been convinced that the database is the embodiment of the business rules.
The business rules don’t need to know about the schema, or the query language, or any of the other details about the database. All the business rules need to know is that there is a set of functions that can be used to fetch or save data.
A computer program is a detailed description of the policy by which inputs are transformed into outputs.
Strictly speaking, business rules are rules or procedures that make or save the business money.
We shall call these rules Critical Business Rules, because they are critical to the business itself, and would exist even if there were no system to automate them.
We shall call this data Critical Business Data. This is the data that would exist even if the system were not automated.
The critical rules and critical data are inextricably bound, so they are a good candidate for an object. We’ll call this kind of object an Entity
Not all business rules are as pure as Entities. Some business rules make or save money for the business by defining and constraining the way that an automated system operates.
The bank may decide that it does not want the loan officers to offer loan payment estimates until they have first gathered, and validated, contact information and ensured that the candidate’s credit score is 500 or higher. For this reason, the bank may specify that the system will not proceed to the payment estimation screen until the contact information screen has been filled out and verified, and the credit score has been confirmed to be greater than the cutoff.
This is a use case.2 A use case is a description of the way that an automated system is used.
A use case describes application-specific business rules as opposed to the Critical Business Rules within the Entities.
Use cases contain the rules that specify how and when the Critical Business Rules within the Entities are invoked. Use cases control the dance of the Entities.
