[Book Review] Clean Architecture Software structure and design learned from masters

The book I read

Clean Architecture Software structure and design learned from masters Robert C. Martin Author I read. This is a book review (reading impression).

Design and architecture objectives

The author first argues for the purpose of design and architecture (the author says design = architecture). Says `" The purpose of software architecture is to minimize the human resources required to build and maintain the required system " For a moment, it became "Hmm?" And I thought it might be so after a while. This isn't about hobbies, it's about developing software as a business. It may not come as a surprise to engineers who think that it is a job, but people who make it as a hobby and do not know maintenance, but it is certainly correct from a business perspective. By the way, I'm an engineer who has grown up by making software while having fun all the time, so I don't think that an engineer who enjoys being caught up in business is bad. (Just having a subordinate would be a pain ...)

In other words ** "Software that is not productive in development and maintenance is badly designed" ** That's why it's quite reasonable. It's a ** that ** that requires a huge amount of man-months every time you fix something. Moreover, it gets worse and worse as the days go by.

So how do you get the right design?

How to design?

Up to the second part, it feels like looking back on the history, so skip it for the time being, and the third part

SRP: Single-responsibility principle
OCP: Open and Closed Principles
LSP: Liskov Substitution Principle
ISP: Segregation principle
DIP: Principle of dependency reversal

Is it around here? These are acronyms ** SOLID Principles **. These are valid ideas for ** "detailed design" ** rather than ** "basic design" ** of the system. The author also says that it "applies above the code level", and ** component design ** awaits further. If you go to ** component design **, it will fall into the category of ** "basic design" **.

But first, "SRP: Single-responsibility principle"

SRP: Single-responsibility principle

This is a rather confusing explanation in this book, but in my understanding it is.

** Responsibility should be MECE **

What is MECE? For those who say Learn the basics of the five frameworks, what is "MECE" Please see around. To put it simply, MECE is an acronym for "Mutually Exclusive and Collectively Exhaustive," which means "without omission and without duplication." Originally McKinsey's internal term, I think you'll often see it in the topic of logical thinking these days. I don't think MECE is all right, but it's a very good concept to explain the "single responsibility principle". I think that this idea is effective for the analysis of all events, and is valuable when applied at any level of basic design and requirements, not at the detailed design level.

OCP: Open and Closed Principles

By considering the direction of encapsulation and dependence, he says, "We should be able to extend existing artifacts without modification." The problem is what the ** existing deliverables ** are, but basically Core part such as business logic Or The side that is located in the lower layer in the hierarchical structure and is called from the upper layer (generally) That would be the case. These ** existing artifacts **, such as class modules and components, must, of course, be properly accounted for by the "single responsibility principle". Classes, modules, components, etc. that have responsibility divided correctly and are only called from the outside are naturally isolated from external changes, so it can be said that they follow the ** open / closed principle **. ..

LSP: Liskov Substitution Principle

The principle and understanding is that Protocol in Swift, Interface in Java, and implementation objects of abstract classes in C ++ should behave according to these interface definitions. If the interface definition is correct and clear, you need to be careful because you just implement it exactly, but it doesn't seem very important.

ISP: Segregation principle

I think the principle is "don't depend on others unnecessarily" and "don't depend on others". If the division of responsibilities is MECE, using the "open and closed principle" to minimize dependencies and designing the appropriate interface, ** dependencies ** will naturally decrease.

Suffice it to say, in the dependency on an interface as described in the "Principle of Dependency Reversal" below, the idea is that one class defines multiple interfaces and does not force the other class to implement unnecessary functions. May be important.

DIP: Principle of dependency reversal

It's almost no longer a reading impression, but I would like to write my own opinion here as well.

First, the dependency is the direction of the join. As mentioned in the "Open / Closed Principle", if A is located in the upper layer (hereinafter referred to as "A layer") and B is located in the lower layer (hereinafter referred to as "B layer") in the normal software structure, A becomes B. Even if it depends, B thinks that it will not cause much problem because there are few changes in the first place.

However, the upper layer A is an invariant module and I do not want to depend on B. But what if you have to call the B function?

The answer is ** "reversal of dependencies" **.

Specifically, it depends on the interface (Swift Protocol, Java Interface), and it doesn't depend on the implementation (object instance), right? That is the "principle of dependency reversal".

In the situation shown above, both A and B depend on the interface. A only calls the function of B as defined in the interface, it doesn't matter who B is. B does not depend on A by implementing it so as not to violate the definition of the interface ("Liskov Substitution Principle"). I think that the expression ** reversal ** is used because of the dependence of this layer A interface.

But I'm a little skeptical that it's up to the owner of the ** interface ** to see if it's reversed. In other words, is the owner of the definition of the interface A or B?

Considering the configuration shown above, it cannot be said that it is a reversal. It seems that Layer B defines an interface with a certain aim to hide an instance of B.

In this way, it is honest that the dependence on the interface itself has a meaning in the design pattern, and you do not have to worry about reversal.

Summary

** Clean Architecture I've just written my thoughts rather than the contents of the software structure and design that I learned from the masters **, but I will summarize it once.

Important in the detailed design of class module components is

Think of your responsibilities as MECE
Thinking about the direction of dependence
Don't depend on it unnecessarily, don't depend on it
Consider relying on the interface if necessary

I think. Almost ** splits and dependencies ** are mentioned.

Finally, the table of contents is given below. Can I write about Part 4 and Part 5 someday ...

table of contents

Part 1 Introduction
Design and architecture
Two values story
Part 2 Start with the components:Programming paradigm
Paradigm overview
Structured programming
Object-oriented programming
Functional programming
Part 3 Design Principles
SRP: Single-responsibility principle
OCP: Open and Closed Principles
LSP: Liskov Substitution Principle
ISP: Segregation principle
DIP: Principle of dependency reversal
Part 4 Component Principles
component
Component condensation
Combine components
Part 5 Architecture
What is architecture?
Independence
Boundary: Draw a border
Boundary anatomy
Policy and level
Business rules
Screaming architecture
Clean architecture
Presenter and Humble Object
Partial boundary
Layers and boundaries
Main component
Service: Everything
Test boundary
Clean embedded architecture
Part 6 Details
abridgement
Part 7 Appendix
abridgement