Building Maintainable Software-java篇之Keep Architecture Components Balanced

Building Maintainable Software-java篇之Keep Architecture Components Balanced

Building encapsulation boundaries is a crucial skill in software architecture.
                    —George H. Fairbanks in Just Enough 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
by Joost Visser
Copyright © 2016 Software Improvement Group, B.V. All rights reserved.
Printed in the United States of America.
Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472.
O’Reilly books may be purchased for educational, business, or sales promotional use. Online editions are
also available for most titles (http://safaribooksonline.com). For more information, contact our corporate/
institutional sales department: 800-998-9938 or [email protected].
Acquisitions Editor: Rachel Roumeliotis
Editor: Nan Barber
Production Editor: Matthew Hacker
Copyeditor: Rachel Monaghan
Proofreader: Marta Justak
Indexer: WordCo Indexing Services, Inc.
Interior Designer: David Futato
Cover Designer: Randy Comer
Illustrator: Rebecca Demarest
February 2016: First Edition
Revision History for the First Edition
2016-01-25: First Release
See  http://shop.oreilly.com/product/0636920049159.do