Building maintainable Software-java article 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 the-
organizing source code in a .
of components is close to 9 (i.e., between 6 and) and that the components are of approximately equal s ize.
? 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, is approximately equal. The architecture then have a goodcomponent balance.
An example of component imbalance would being has a few very large componentsThat contain a disproportionate amount of system logic and many small ones thatdwindle in comparison.
MotivationNow we know what component balance are, but isn't why it's important. The reason is simple:software maintenance was easier when the software architecture was 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 Mainte Nance, and it separates maintenance responsibilities.
A Good Component Balance eases finding and analyzing CodeA Clear Code organization in components makes it easier to find the piece of code
You want to the 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 are consistent, they allow for a
Drill-down each time this need to analyze code to modify it.
In contrast, an unbalanced organization of are more likely to has unclear
functional boundaries. For example, a component that's very large compared to oth‐
ers is more likely to contain functionalities that's 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 had a
proper separation of concerns, which makes for isolated behavior in the system. Iso‐
lated behavior within system components are relevant because it guards against unex‐
pected effects, such as regression.
More broadly, isolation of code within components have the general advantage of
modularity:components with clear functional and technical boundaries is 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 the does not necessarily make
Those components independent from each of the other . So, the degree of dependence
between components are relevant as well, as we'll discuss in Chapter 7.
A Good Component Balance separates maintenance responsibilities
Have 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 had too many or too few components, it was considered more difficult
To understand and harder to maintain. If the number of the components are too low, it
does not much to navigate through the functionalities of the system. on the
Other hand, too many-it hard-get a clear overview of the entire
System.
How to Apply the guideline
The principles of component balance are:
betwe En 6 and.
note that component balance was an indicator for a clear component
Span style= "font-size:18px" >separation, not a goal in itself. It should follow from the system
design and development process. The division of the system into
components should is natural, not forced to nine co Mponents for
the sake of have nine components.
Decide on the right conceptual level for Grouping functionality to components
To achieve a good the system division that's easy-to-navigate for developers, and you need to
Choose the right conceptual level for grouping functionality. Usually, software systems
is 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 the components have been made, you
need to apply it consistently. An inconsistent architecture was a bad architecture.
therefore, the division into components should is formalized and controlled. While
making The design choices is an architect's role, the discipline to creat E and
respect the component boundaries in the code organization applies to all Deve Lopers.
a-to achieve-is-agree as A team in which components certain changes Need
To is implemented. It's a collective responsibility to ensure, that's the done in a consistent manner.
Reading notes:
Building maintainable Software:ten guidelines for Future-proof Code
by Joost Visser
Copyright? Software improvement Group, B.V. All rights reserved.
Printed in the states of America.
Published by O ' Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472.
O ' Reilly Books is purchased for educational, business, or sales promotional use. Online Editions is
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
Building maintainable Software-java article keep Architecture components Balanced
