本文是《Clean Architecture A Craftsman Guide to Software Structure and Design》的阅读笔记, 通过 MindMap 记录, 通过一些方法转换成 markdown, 图片无法显示, 用于未来参考和检阅.

  • Clean Architecture
    • PART I Introduction
      • Chapter 1 What Is Design and Architecture?
        • goal of software architecture
        • a familiar lie: 「We can clean it up later; we just have to get to market first!」
        • making messes is always slower than staying clean
        • The only way to go fast, is to go well
      • Chapter 2 A Tale of Two Values
        • behavior and structure
          • Behavior
          • Architecture
        • Eisenhower』s Matrix
          • Fight for the Architecture
          • as a software developer, you are a stakeholder.
            • If architecture comes last, then the system will become ever more costly to develop, and eventually change will become practically impossible for part or all of the system.
              • If that is allowed to happen, it means the software development team did not fight hard enough for what they knew was necessary.
    • PART II Starting with the Bricks: Programming Paradigms
      • Chapter 3 Paradigm Overview
      • Chapter 4 Structured Programming
        • Proof
        • A Harmful Proclamation
        • Functional Decomposition
        • No Formal Proofs
        • Science to the Rescue
        • Tests
        • Conclusion
      • Chapter 5 Object-Oriented Programming
        • three magic words to explain the nature of OO: encapsulation, inheritance, and polymorphism
          • Encapsulation?
          • Inheritance?
          • Polymorphism?
        • 一种传统的系统设计事件工作流
        • 依赖反转
          • 因为这个原因可以降低类和类之间的依赖，同时解耦
            • 同时，因为这个优势使得总监可以进行独立的部署更改以及维护
        • Conclusion
          • OO is the ability, through the use of polymorphism, to gain absolute control over every source code dependency in the system.
          • The low-level details are relegated to plugin modules that can be deployed and developed independently from the modules that contain high-level policies.
          • It allows the architect to create a plugin architecture, in which modules that contain high-level policies are independent of modules that contain low-level details.
      • Chapter 6 Functional Programming
        • Immutability and Architecture
          • immutability can be practicable, if certain compromises are made
        • Segregation of Mutability
          • The point is that well-structured applications will be segregated into those components that do not mutate variables and those that do.
        • Event Sourcing
          • Event sourcing
            • As a consequence, our applications are not CRUD; they are just CR
        • Conclusion
    • PART III Design Principles
      • Chapter 7 SRP: The Single Responsibility Principle
        • Symptom 1: Accidental Duplication
        • Symptom 2: Merges
        • Solutions
        • Conclusion
        • A module should have one, and only one, reason to change.
        • separate the code that different actors depend on
        • Chapter 8 OCP: The Open-Closed Principle
        • A Thought Experiment
        • Directional Control
        • Information Hiding
        • Conclusion
      • Chapter 9 LSP: The Liskov Substitution Principle
        • Guiding the Use of Inheritance
        • The Square/Rectangle Problem
        • LSP and Architecture
        • Example LSP Violation
        • Conclusion
      • Chapter 10 ISP: The Interface Segregation Principle
        • ISP and Language
        • ISP and Architecture
        • Conclusion
      • Chapter 11 DIP: The Dependency Inversion Principle
        • Stable Abstractions
          • Don』t refer to volatile concrete classes. Refer to abstract interfaces instead
          • Don』t derive from volatile concrete classes
          • Don』t override concrete functions.
            • When you override those functions, you do not eliminate those dependencies—indeed, you inherit them.
          • Never mention the name of anything concrete and volatile.
        • Factories
          • Concrete Components
        • Conclusion
    • PART IV Component Principles
      • Chapter 12 Components
        • A Brief History of Components
          • Components
        • Relocatability
        • Linkers
        • Conclusion
      • Chapter 13 Component Cohesion
        • Summary
          • finds a position in that tension triangle that meets the current concerns
        • REP
          • The granule of reuse is the granule of release
        • CCP
          • a component should not have multiple reasons to change.
        • CRP
        • The Tension Diagram for Component Cohesion
        • Conclusion
      • Chapter 14 Component Coupling
        • The Acyclic Dependencies Principle
          • 一个环状依赖的例子
            • BREAKING THE CYCLE
              • Dependency Inversion Principle
                • Create a new component that both Entities and Authorizer depend on
                • Top-Down Design
        • The Stable Dependencies Principle
          • The SDP says that the I metric of a component should be larger than the I metrics of the components that it depends on. That is, I metrics should decrease in the direction of dependency.
            • 一个典型的关于依赖逐步下降的例子
              • 一个典型的违反 SDP 的例子
            • 如何打破依赖
              • Abstract Components
        • The Stable Abstractions Principle
          • A component should be as abstract as it is stable.
          • Stable Abstractions Principle; SAP
          • MEASURING ABSTRACTION
            • DISTANCE FROM THE MAIN SEQUENCE
            • Distance. D = |A+I–1| . The range of this metric is [0, 1]
        • Conclusion
    • PART V Architecture
      • Chapter 15 What Is Architecture?
        • Development
        • Deployment
        • Operation
        • Maintenance
        • Keeping Options Open
          • maximizes the number of decisions not made
        • Device Independence
        • Junk Mail
        • Physical Addressing
        • Conclusion
        • First of all, a software architect is a programmer; and continues to be a programmer.
          • Software architects may not write as much code as other programmers do, but they continue to engage in programming tasks
      • Chapter 16 Independence
        • Use Cases
        • Operation
        • Development
        • Deployment
        • Leaving Options Open
        • Decoupling Layers
        • Decoupling Use Cases
        • Decoupling Mode
        • Independent Develop-ability
        • Independent Deployability
        • Duplication
        • Decoupling Modes (Again)
          • Summary
          • Source level
          • Deployment level
          • Service level
        • Conclusion
      • Chapter 17 Boundaries: Drawing Lines
        • A Couple of Sad Stories
        • FitNesse
        • Which Lines Do You Draw, and When Do You Draw Them?
        • What About Input and Output?
        • Plugin Architecture
        • The Plugin Argument
        • Conclusion
      • Chapter 18 Boundary Anatomy
        • Boundary Crossing
        • The Dreaded Monolith
        • Deployment Components
        • Threads
        • Local Processes
        • Services
        • Conclusion
      • Chapter 19 Policy and Level
        • Level
        • Conclusion
          • example
            • 更加抽象的依赖图
      • Chapter 20 Business Rules
        • Entities
          • Entity
            • The Entity is pure business and nothing else.
        • Use Cases
          • use cases 不应该知道任何 entity 的内容
          • 用例和实体对象应该完全隔离 否则最终就会出现一堆逻辑
        • Request and Response Models
        • Conclusion
      • Chapter 21 Screaming Architecture
        • The Theme of an Architecture
        • The Purpose of an Architecture
        • But What About the Web?
        • Frameworks Are Tools, Not Ways of Life
        • Testable Architectures
        • Conclusion
      • Chapter 22 The Clean Architecture
        • The Dependency Rule
        • A Typical Scenario
        • Conclusion
        • clean architecture 的几个要点
          • Independent of the UI
          • Independent of the database
          • Independent of any external agency
          • Independent of frameworks
          • Testable
        • 架构概念图
          • Chapter 23 Presenters and Humble Objects
        • The Humble Object Pattern
          • Humble Object pattern
            • 分离易于测试和难于测试的组件
        • Presenters and Views
        • Testing and Architecture
        • Database Gateways
        • Data Mappers
        • Service Listeners
        • Conclusion
      • Chapter 24 Partial Boundaries
        • Skip the Last Step
        • One-Dimensional Boundaries
        • Facades
        • Conclusion
      • Chapter 25 Layers and Boundaries
        • Hunt the Wumpus
        • Clean Architecture?
        • Crossing the Streams
        • Splitting the Streams
        • Conclusion
      • Chapter 26 The Main Component
        • The Ultimate Detail
        • Conclusion
      • Chapter 27 Services: Great and Small
        • Service Architecture?
        • Service Benefits?
          • THE DECOUPLING FALLACY
        • The Kitty Problem
        • Objects to the Rescue
        • Component-Based Services
        • Cross-Cutting Concerns
        • Conclusion
      • Chapter 28 The Test Boundary
        • Tests as System Components
          • Tests, by their very nature, follow the Dependency Rule; they are very detailed and concrete; and they always depend inward toward the code being tested. In fact, you can think of the tests as the outermost circle in the architecture
        • Design for Testability
          • Tests that are strongly coupled to the system must change along with the system
        • The Testing API
        • Conclusion
      • Chapter 29 Clean Embedded Architecture
        • App-titude Test
        • The Target-Hardware Bottleneck
        • Conclusion
    • PART VI Details
      • Chapter 30 The Database Is a Detail
        • Relational Databases
        • Why Are Database Systems So Prevalent?
        • What If There Were No Disk?
        • Details
        • But What about Performance?
        • Anecdote
        • Conclusion
      • Chapter 31 The Web Is a Detail
        • The Endless Pendulum
        • The Upshot
        • Conclusion
      • Chapter 32 Frameworks Are Details
        • Framework Authors
        • Asymmetric Marriage
        • The Risks
        • The Solution
        • I Now Pronounce You …
        • Conclusion
      • Chapter 33 Case Study: Video Sales
        • The Product
        • Use Case Analysis
        • Component Architecture
        • Dependency Management
        • Conclusion
      • Chapter 34 The Missing Chapter
        • Package by Layer
        • Package by Feature
        • Ports and Adapters
        • Package by Component
        • The Devil Is in the Implementation Details
        • Organization versus Encapsulation
        • Other Decoupling Modes
        • Conclusion: The Missing Advice