Skip to content

Components

Jump to bottom
serhij.zolotukhin edited this page Dec 7, 2025 · 1 revision

Why:

  1. redeploying only those components
  2. isolated components

How to:

  1. partition the classes in an application according to some criteria
  2. allocate the classes in those partitions to independently deployable components
  3. design at a higher level of abstraction

Questions:

  1. What are the principles for allocating classes to components?

REP - Reuse/Release Equivalence Principle - The granule of reuse is the granule of release. Thus, REP states that the granule of reuse, a component, can be NO SMALLER than the granule of RELEASE. As new releases of a component are made, other teams can decide whether to immediately adopt the new release. The integration happens in small increments.

CRP - The Common Reuse Principle - The classes in a component are reused together. If you reuse one of the classes in a component, you reuse them all. Either ALL the classes in a component are reusable, or NONE of them are.

CCP - Common Closure Principle - The classes in a component should be closed together against the same kinds of changes. A change that affects a component affects all the classes in that component and no other components. This is the Single-Responsibility Principle (SRP) restated for components. CCP says that a component should not have multiple reasons to change.

  1. What design principles govern the relationships between components?

ADP - The Acyclic Dependencies Principle - Allow no cycles in the component dependency graph.

SDP - The Stable-Dependencies Principle - Depend in the direction of stability. We ensure that modules that are intended to be easy to change are not depended on by modules that are more difficult to change than they are. Stability - is related to the amount of work required to make a change. A component with lots of components depending on it is very stable.

SAP - The Stable-Abstractions Principle - A component should be as abstract as it is stable. It says that a stable component should also be abstract so that its stability does not prevent it from being extended.

  1. Should components be designed before classes (top down)? Or should classes be designed before components (bottom up)?

see: "Agile Principles, Patterns, and Practices in C#" By Martin C. Robert, Martin Micah

My footer

My side bar

Clone this wiki locally