reuse is the granule of release •The classes and modules that are formed into a component must belong to a cohesive group •Classes and modules that are grouped together in a component should be released together
those classes that change for the same reasons and at the same time. Separate into different components those classes that change at different times and for different reasons. •Single Responsibility Principle for components •Closely associated with Open-Closed Principle
of a component to depend on things they don’t need • Tells us which classes to put into a component and which ones to not keep together • Related to the Interface Segregation Principle
direction of stability • Some components are designed to be volatile (we expect them to change). • If a component is difficult to change, it should not depend on a volatile component.
classes outside a component that depend on classes inside the component Fan-Out The number of classes inside a component that depend on classes outside the component Instability = Fan-out Fan-in + Fan-out Instability = 0 => maximum stability Instability = 1 => minimal stability
as it is stable A stable component should also be abstract An unstable component should be concrete Abstractness = Number of abstract classes and interfaces in a component Number of classes in the component Abstractness = 0 => No abstraction Abstractness = 1 => Completely abstract
of that shape is the division of that system into components, the arrangement of those components, and the ways in which those components communicate with each other. “ - “Uncle” Bob Martin, Clean Architecture
Operation • Throughput, Scalability Development • Conway’s Law – Any organization that designs a system will produce a design whose structure is a copy of the organization’s communication structure Deployment • Often an after-thought Leaves options open • Balance these concerns with a component structure that satisfies them all