Building encapsulation boundaries is a crucial skill in software architecture.

Guideline:

? Balance the number and relative size of top-level components in your code.

? Do this by organizing source code in a way that the number of components is close to 9 (i.e., between 6 and 12) and that the
components are of approximately equal size.

? This improves maintainability because balanced components

ease locating code and allow for isolated maintenance.

A well-balanced software architecture is one with not too many and not too few components, with sizes that are approximately equal. The architecture then has a good component
balance.

An example of component imbalance would be having a few very large components that contain a disproportionate amount of  system logic and many small ones that dwindle
in comparison.

Motivation

Now we know what component balance is, but not why it is important. The reason is simple: software maintenance is easier when the software architecture
is balanced.

This section discusses in what ways you can benefit from a good system component balance: it makes it easier to find and analyze code, it better isolates effects of maintenance,
and it separates maintenance responsibilities.

A Good Component Balance Eases Finding and Analyzing Code

A clear code organization in components makes it easier to find the piece of code that

you want to change. Of course, proper code hygiene helps in this process as well, such

as using a consistent naming convention (see Chapter 11). When the number of com‐

ponents is manageable (around nine) and their volume is consistent, they allow for a

drill-down each time that you need to analyze code to modify it.

In contrast, an unbalanced organization of components is more likely to have unclear

functional boundaries. For example, a component that is very large compared to oth‐

ers is more likely to contain functionalities that are unrelated, and therefore that

component is harder to analyze.

A Good Component Balance Better Isolates MaintenanceEffects

When a system’s component balance clearly describes functional boundaries, it has a

proper separation of concerns, which makes for isolated behavior in the system. Iso‐

lated behavior within system components is relevant because it guards against unex‐

pected effects, such as regression.

More broadly, isolation of code within components has the general advantage of

modularity: components with clear functional and technical boundaries are easier to

substitute, remove, and test than components with mixed functionalities and techni‐

cal intertwinement.

Note that a good component balance in itself clearly does not guarantee isolation of

changes. After all, grouping code in different components does not necessarily make

those components independent from each other. So, the degree of dependence

between components is relevant as well, as we will discuss in Chapter 7.

A Good Component Balance Separates Maintenance Responsibilities

Having clear functional boundaries between components makes it easier to distribute

responsibilities for maintenance among separate teams. The number of components

of a system and their relative size should indicate the system’s decomposition into

functional groups.

When a system has too many or too few components, it is considered more difficult

to understand and harder to maintain. If the number of components is too low, it

does not help you much to navigate through the functionalities of the system. On the

other hand, too many components make it hard to get a clear overview of the entire

system.

How to Apply the Guideline

The two principles of component balance are:

? The number of top-level system components should ideally be 9, and generally

between 6 and 12.

? The components’ volume in terms of source code should be roughly equal.

Note that component balance is an indicator for a clear component

separation, not a goal in itself. It should follow from the system

design and development process. The division of the system into

components should be natural, not forced to nine components for

the sake of having nine components.

Decide on the Right Conceptual Level for Grouping Functionality into Components

To achieve a good system division that is easy to navigate for developers, you need to

choose the right conceptual level for grouping functionality. Usually, software systems

are organized along high-level functional domains that describe what kind of func‐

tions the system performs for the user. Alternatively, a division is made along the sep‐

arations of technical specialities.

Clarify the System’s Domains and Apply Those Consistently

Once a choice for the type of system division into components has been made, you

need to apply it consistently. An inconsistent architecture is a bad architecture.

Therefore, the division into components should be formalized and controlled. While

making the design choices may be an architect’s role, the discipline to create and

respect the component boundaries in the code organization applies to all developers.

A way to achieve this is to agree as a team in which components certain changes need

to be implemented. It is a collective responsibility to ensure that this is done in a consistent manner.

读书笔记：

Building Maintainable Software: Ten Guidelines for Future-Proof Code

See  http://shop.oreilly.com/product/0636920049159.do