More on this book
Community
Kindle Notes & Highlights
Software architects are the best programmers, and they continue to take programming tasks, while they also guide the rest of the team toward a design that maximizes productivity.
The architecture of a software system is the shape given to that system by those who build it.
The primary purpose of architecture is to support the life cycle of the system.
A software system that is hard to develop is not likely to have a long and healthy lifetime.
The higher the cost of deployment, the less useful the system is.
The fact that hardware is cheap and people are expensive means that architectures that impede operation are not as costly as architectures that impede development, deployment, and maintenance.
A good software architecture communicates the operational needs of the system.
Of all the aspects of a software system, maintenance is the most costly.
The primary cost of maintenance is in spelunking and risk.
Spelunking is the cost of digging through the existing software, trying to determine the best place and the best strategy to add a new feature or to repair a defect.
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.
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.
You draw lines between things that matter and things that don’t.
All the business rules need to know is that there is a set of functions that can be used to fetch or save data.
We don’t want changes in one part of the system to cause other unrelated parts of the system to break.
Arranging our systems into a plugin architecture creates firewalls across which changes cannot propagate.
Boundaries are drawn where there is an axis of change.
At runtime, a boundary crossing is nothing more than a function on one side of the boundary calling a function on the other side and passing along some data.
The services assume that all communications take place over the network.
A computer program is a detailed description of the policy by which inputs are transformed into outputs.
Policies that change for the same reasons, and at the same times, are at the same level and belong together in the same component.
The farther a policy is from both the inputs and the outputs of the system, the higher its level.
Strictly speaking, business rules are rules or procedures that make or save the business money.
A use case is a description of the way that an automated system is used.
Entities are generalizations that can be used in many different applications, so they are farther from the inputs and outputs of the system.
The use case class accepts simple request data structures for its input, and returns simple response data structures as its output.
The business rules should be the most independent and reusable code in the system.
A good architecture emphasizes the use cases and decouples them from peripheral concerns.
The architecture of a system is defined by boundaries that separate high-level policy from low-level detail and follow the Dependency Rule.
Service interfaces are no more formal, no more rigorous, and no better defined than function interfaces.
Tests are the most isolated system component.
The role of the testing API is to hide the structure of the application from the tests.
Firmware does not mean code lives in ROM.
The name of the boundary between the software and the firmware is the hardware abstraction layer (HAL)
Certainly, all of the software should be processor independent, but not all of the firmware can be.
Limit the visibility of the implementation details. Expect the implementation details to change. The fewer places where code knows the details, the fewer places where code will have to be tracked down and modified.
The database is a utility that provides access to the data.
The rotating magnetic disk was the mainstay of data storage for five decades.
Even though the data is kept in a database or a file system, you read it into RAM and then you reorganize it, for your own convenience, into lists, sets, stacks, queues, trees, or whatever data structure meets your fancy.
The GUI is a detail. The web is a GUI. So the web is a detail.
The WEB is an IO device.
The author recommends that you derive from the framework’s base classes, and import the framework’s facilities into your business objects.
Nothing feels more validating to a framework author than a bunch of users willing to inextricably derive from the author’s base classes.
When faced with a framework, try not to marry it right away.
Perhaps you can find a way to get the milk without buying the cow.
Our first step in determining the initial architecture of the system is to identify the actors and use cases.
An abstract use case is one that sets a general policy that another use case will flesh out.
In Java, layers are typically implemented as packages.
