Clean Architecture - Examples for "The Triad of Component Principles"

Question

I'm in the midst of reading Clean Architecture on the "Component Principles" part.

There, the author explains three principles for component design. I think I kind of understand them in isolation.

Reuse / Release Equivalence Principle (REP)
My understanding of this one is that packages, for them to be reusable, need to have proper release tracking mechanisms (versions, docs, etc)

Common Closure Principle (CCP)
This one states that classes which change for the same reason need to be bundled in the same package. The goal is achieving maintainability -> If something in your app changes, it will likely change in a single package (or only a few).

Common Reuse Principle (CRP)
If a user depends on a package, they should depend on all classes in that package.
Meaning that, a package should contain only those classes which are reused together.

After going through these principles, the author shows this "triad" of the principles, which resembles the classic CAP theorem:

My understanding of this is that when designing components, you can only choose to follow two of the three principles.

And that's the part I don't quite understand:

1. I don't see how using REP is exclusive to either of the other principles. To my understanding, satisfying REP means implementing release management mechanisms. I don't see how sticking to both CCP and CRP can prohibit that?
2. How can CCP and CRP ever be used together? I see them as totally opposite principles. The former states that classes should be grouped in a way that they are changed together, while the latter states that classes should be grouped in a way that they are used together. I see these two as opposite goals and I don't see how they can be achieved together.

Would be glad if someone helps in debunking these principles as the book lacks any practical examples of the possible "triad pairs" - e.g. REP and CRP, REP and CCP, CCP and REP.

If someone can provide those missing examples of the possible pairs, it would be great!

Answer 1

I misunderstood this diagram at first too. What helped me is searching for Robert C. Martin talks about "Component Principles".

Really recommend this talk on Youtube (about this diagram start from 30:43). It just has more clear explanations for me comparing to the book.

In short, this diagram has nothing to do with pairs. It just shows drawbacks of not using one of those principles.

• If you don't implement CRP you will have too many unneeded releases
• If you don't implement REP components will become hard to reuse
• If you don't implement CCP 1 change can affect too many components

Answer 2

Common Closure Principle: Don't make components in an application too broad.

Components which tend to be updated together should be grouped together. If many components require updates when one change is made, there is likely coupling between the components. As the degree of coupling between components increases, so does the likelihood of a minor change in one component having broad effects because of unexpected use cases and imperfect documentation.

Common Reuse Principle: Don't make components in an application too specific.

If the user of the component needs one part of a component, all parts of the component should be included (because they are relevant/needed). From the user perspective, a component should do one thing well. All logic that builds up that 'one thing' should be included in the component. The main benefit of packaging logic into components is to improve usability and maintainability and the unit of re-use should be the unit at which re-use is useful.

Reuse/Release Equivalence Principle: Don't assume a component is perfect as is.

Manually passing around a single class is unmaintainable. For a given component to be useful, there must be a mechanism to provide long term stability (ex: issues fixed as they are noticed, etc). As such, there should be a some form of release flow where issues can be logged and updated versions of the component can be found and used.

Trade-offs need to be considered when determining how specific/broad a given component should be both from a usability and maintainability perspective.

1. CCP not followed? Components can't be maintained. Tough to fix issues/add enhancements.
2. CRP not followed? Components are not useful. Tough to use components.
3. REP not followed? Components can't be trusted. Tough to use components.

There are trade-offs, but comparing to CAP seems like a bit of a stretch. CAP is more of a 'pick your poison' while this is more of a 'remember why the component is being written'. I tend to think there is some subjective optimal structure which provides usable and trustworthy components. CAP states objectively only 2 can be chosen.