Clean Architecture Chapter 13: Component Cohesion

[Israel Fonseca]

I have a study group and we are reading the book "together", and weekly we have a discussion about the topics of every chapter (sometimes more than a single chapter). In the last one about Component Cohesion, we had a lot of problems to understand the concepts without concrete examples. Can you guys help me to give a concrete example of practice or structure that is the outcome of following each principle?:

- CRP: Is this a "micro service architecture"?

- CCP: Is this a "Monolith" architecture? Is this having a .jar file to hold UseCases/Interactors and also concrete implementations of Gateways?

- REP: This one (as the book suggest) was very hard to understand, does this ONLY means to put version on libraries? The book give so much emphasis on that, that we almost started to think so.

- After a long discussion about the Tension Diagram at some point it seemed to us that the REP principle is "useless" (or maybe so obvious that we can't understand), and actually the only two points that you may follow in architecture is going towards CCP or CRP.

- CCP and CRP are extremely opposite to each other. What is a concrete "balanced" example of following both?

Maybe the answers are in the following chapters, but we didn't get in there yet. So you guys could just give me the spoiler and I wouldn't mind.

[Robert C. Martin]

On Nov 8, 2017, at 16:15 , Israel Fonseca <israe...@gmail.com> wrote:

I have a study group and we are reading the book "together", and weekly we have a discussion about the topics of every chapter (sometimes more than a single chapter). In the last one about Component Cohesion, we had a lot of problems to understand the concepts without concrete examples. Can you guys help me to give a concrete example of practice or structure that is the outcome of following each principle?:

- CRP: Is this a "micro service architecture”?

No.  First of all, micro-services are not an architecture, they are an implementation detail.  The service boundary is simply an abstraction of an asynchronous function call. 

CRP is a principle about components; which are the fundamental elements of an architecture.  The CRP says that a component should be so cohesive that if another component uses it, it uses every aspect of it.  So, for example, if component A offers four services, and if component B uses component A, then component B will use all four services of A.  

The point is that we don’t want components to be loose conglomerations of random services.  We want the services offered by a component to be a single abstraction.

- CCP: Is this a "Monolith" architecture? Is this having a .jar file to hold UseCases/Interactors and also concrete implementations of Gateways?

No, once again, monoliths are not architectures.  Monoliths are just one way to implement an architecture by confining all the components of that architecture in the same executable. 

CCP says that when the application changes for a single reason, then only a single component (or single family of components) should require changing.  This tries to avoid the anti-pattern of “Shotgun Surgery”.  Shotgun surgery is when a single change to the requirements causes many different and unrelated components to change.  

  

- REP: This one (as the book suggest) was very hard to understand, does this ONLY means to put version on libraries? The book give so much emphasis on that, that we almost started to think so.

The REP says that if you want a component to be reusable in many different applications; then the component must be something you are willing to put through a release process, with release numbers and release notes, etc.  You must also take care of those who use your component by notifying them about new releases and offering them some way to continue to use older versions.

- After a long discussion about the Tension Diagram at some point it seemed to us that the REP principle is "useless" (or maybe so obvious that we can't understand), and actually the only two points that you may follow in architecture is going towards CCP or CRP.

Yes, that’s quite true in early development.  CCP and CRP are the most important then.  REP becomes much more important once you decide to offer your components to other applications for reuse.

- CCP and CRP are extremely opposite to each other. What is a concrete "balanced" example of following both?

Ah!  Therein lies the magic.  It depends entirely on how much the components and the application are likely to change.  If new features are constantly being added to the application and older features are being changed, then the CCP starts to look very important because you want to isolate that change into as few components as possible.  If, however, the application is relatively stable, and you are making small tweaks from time to time, then the CRP starts to outweigh the CCP.  You’ll want to reduce the number of components to help make the system more manageable.  This will weaken the CCP, and increase the chances that you will violate the CRP.  

That’s why it’s a “tension” diagram.  It’s all about the forces that are _currently_ being put upon the architecture of the system.  As those forces change, some principles become more important, others become less so; and the architecture of the system shifts to accommodate.

Maybe the answers are in the following chapters, but we didn't get in there yet. So you guys could just give me the spoiler and I wouldn't mind.

--
The only way to go fast is to go well.
---
You received this message because you are subscribed to the Google Groups "Clean Code Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clean-code-discu...@googlegroups.com.
To post to this group, send email to clean-code...@googlegroups.com.
Visit this group at https://groups.google.com/group/clean-code-discussion.

Robert C. Martin (Uncle Bob) | uncl...@cleancoders.com
Clean Coders                 | @unclebobmartin
847.922.0563                 | cleancoders.com

[Israel Fonseca]

Thanks for the clarifications Uncle Bob, but when I wrote about a "micro service architecture" I was trying to use it in the same sense that you used in the Chapter 15 - Deployment. By having component boundaries so firm and interfaces relatively stable (result of the "microservice architecture"[emphasis on the quotes]) a team tend to favor the CRP. And the opposite, "Monolith Architecture" tend to favor the CCP.

Another question: our project (which is a monolith written in python) have this folder structure:

core/

core/payment

core/payment/usecases/

core/payment/entities/

...

core/account_creation

core/account_creation/usecases

core/account_creation/entities

...

framework/

framework/controllers

framework/models

...

All the source code is in the same git repo, and when we change something we actually redeploys the whole system (which is fast enough for us, allowing a lot of production deployments per day). Given that, can we call the "payment" and the "account_creation" packages as "components", even that they can't be deployed independently? 

And given this context, some more questions:

- By separating in packages (or components) the common features, are we following the CRP? Or is it actually CCP because changes tend to happen in small portions of code?

- Given that our POST /account endpoint only uses the Account Creation usecase, can we say that the CRP is being respected?

- Given that all of this code is versioned together (all in the same repo) could we say that our REP is not "that good"?

Thanks again for the clarifications,