清洁架构：程序员的软件结构与设计指南

architecture

5星 · 超过95%的资源需积分: 10 135 浏览量更新于2024-07-18 1 收藏 8.06MB PDF 举报

身份认证购VIP最低享 7 折!

30元优惠券

"Clean Architecture是Robert C. Martin撰写的一本关于软件结构和设计的工匠指南，主要探讨了软件架构的清洁原则和实践。" 在软件开发领域，"Clean Architecture"（清洁架构）是一种设计理念，旨在创建可维护、可扩展且与框架无关的软件系统。由知名程序员和敏捷开发倡导者Robert C. Martin（Bob大叔）提出的这一概念，强调了将业务逻辑与技术细节分离的重要性。这本书详细阐述了如何构建一个清晰、模块化的架构，以便于团队协作，降低维护成本，并提高代码质量。 "Clean Architecture"的核心原则是围绕“依赖倒置”原则展开的，即高层模块不应该依赖于低层模块，两者都应该依赖于抽象。这种设计允许开发者独立地修改系统的各个部分，而不影响其他组件。书中介绍了八种不同的架构层，包括实体（Entities）、接口适配器（Interface Adapters）、应用服务（Application Services）、用例（Use Cases）、驱动器（Drivers）、框架和库（Frameworks & Libraries）、基础设施（Infrastructure）以及外部世界（External World），并解释了它们之间的关系和交互方式。书中的编程代码和配置示例是理解架构设计的关键。在阅读电子版时，为了更好地展示这些元素，建议调整设备设置，如采用单列、横屏模式，并将字体调至最小，以适应代码的流动布局。对于可能因流动格式影响代码呈现的情况，书中有提供“点击此处查看代码图像”的链接，点击后可以查看与印刷版一致的代码图像。此外，书中还涵盖了如何进行测试驱动开发（TDD）和行为驱动开发（BDD），以及如何确保业务规则不受外部依赖的影响。Martin提倡的这些原则和实践对于任何希望提升软件项目质量和可维护性的开发者来说，都是宝贵的指导。 “Clean Architecture”是一本深入浅出的著作，它不仅适合经验丰富的软件架构师，也对初入行业的程序员具有很高的学习价值。通过遵循书中的指导，开发者能够构建出更健壮、更具弹性的软件系统，从而在快速变化的技术环境中保持竞争力。

资源详情

资源推荐

of structures—but its variety eclipses the range of physical structure found in

buildings. You can even argue quite convincingly that there is more design activity

and focus in software than in building architecture—in this sense, it’s not

unreasonable to consider software architecture more architectural than building

architecture!

But physical scale is something humans understand and look for in the world.

Although appealing and visually obvious, the boxes on a PowerPoint diagram are not

a software system’s architecture. There’s no doubt they represent a particular view of

an architecture, but to mistake boxes for the big picture—for the architecture—is to

miss the big picture and the architecture: Software architecture doesn’t look like

anything. A particular visualization is a choice, not a given. It is a choice founded on

a further set of choices: what to include; what to exclude; what to emphasize by

shape or color; what to de-emphasize through uniformity or omission. There is

nothing natural or intrinsic about one view over another.

Although it might not make sense to talk about physics and physical scale in

software architecture, we do appreciate and care about certain physical constraints.

Processor speed and network bandwidth can deliver a harsh verdict on a system’s

performance. Memory and storage can limit the ambitions of any code base.

Software may be such stuff as dreams are made on, but it runs in the physical world.

This is the monstrosity in love, lady, that the will is infinite, and the execution confined;

that the desire is boundless, and the act a slave to limit.

—William Shakespeare

The physical world is where we and our companies and our economies live. This

gives us another calibration we can understand software architecture by, other less

physical forces and quantities through which we can talk and reason.

Architecture represents the significant design decisions that shape a system, where

significant is measured by cost of change.

—Grady Booch

Time, money, and effort give us a sense of scale to sort between the large and the

small, to distinguish the architectural stuff from the rest. This measure also tells us

how we can determine whether an architecture is good or not: Not only does a good

architecture meet the needs of its users, developers, and owners at a given point in

time, but it also meets them over time.

If you think good architecture is expensive, try bad architecture.

—Brian Foote and Joseph Yoder

The kinds of changes a system’s development typically experiences should not be

the changes that are costly, that are hard to make, that take managed projects of their

own rather than being folded into the daily and weekly flow of work.

That point leads us to a not-so-small physics-related problem: time travel. How do

we know what those typical changes will be so that we can shape those significant

decisions around them? How do we reduce future development effort and cost

without crystal balls and time machines?

Architecture is the decisions that you wish you could get right early in a project, but that

you are not necessarily more likely to get them right than any other.

—Ralph Johnson

Understanding the past is hard enough as it is; our grasp of the present is slippery at

best; predicting the future is nontrivial.

This is where the road forks many ways.

Down the darkest path comes the idea that strong and stable architecture comes from

authority and rigidity. If change is expensive, change is eliminated—its causes

subdued or headed off into a bureaucratic ditch. The architect’s mandate is total and

totalitarian, with the architecture becoming a dystopia for its developers and a

constant source of frustration for all.

Down another path comes a strong smell of speculative generality. A route filled

with hard-coded guesswork, countless parameters, tombs of dead code, and more

accidental complexity than you can shake a maintenance budget at.

The path we are most interested is the cleanest one. It recognizes the softness of

software and aims to preserve it as a first-class property of the system. It recognizes

that we operate with incomplete knowledge, but it also understands that, as humans,

operating with incomplete knowledge is something we do, something we’re good at.

It plays more to our strengths than to our weaknesses. We create things and we

discover things. We ask questions and we run experiments. A good architecture

comes from understanding it more as a journey than as a destination, more as an

ongoing process of enquiry than as a frozen artifact.

Architecture is a hypothesis, that needs to be proven by implementation and measurement.

—Tom Gilb

To walk this path requires care and attention, thought and observation, practice and

principle. This might at first sound slow, but it’s all in the way that you walk.

hardware over the same half-century. I started programming on machines the size of

kitchen refrigerators that had half-megahertz cycle times, 4K of core memory, 32K

of disk memory, and a 10 character per second teletype interface. I am writing this

preface on a bus while touring in South Africa. I am using a MacBook with four i7

cores running at 2.8 gigahertz each. It has 16 gigabytes of RAM, a terabyte of SSD,

and a 2880×1800 retina display capable of showing extremely high-definition video.

The difference in computational power is staggering. Any reasonable analysis will

show that this MacBook is at least 10

more powerful than those early computers

that I started using half a century ago.

Twenty-two orders of magnitude is a very large number. It is the number of

angstroms from Earth to Alpha-Centuri. It is the number of electrons in the change in

your pocket or purse. And yet that number—that number at least—is the

computational power increase that I have experienced in my own lifetime.

And with all that vast change in computational power, what has been the effect on

the software I write? It’s gotten bigger certainly. I used to think 2000 lines was a big

program. After all, it was a full box of cards that weighed 10 pounds. Now, however,

a program isn’t really big until it exceeds 100,000 lines.

The software has also gotten much more performant. We can do things today that we

could scarcely dream about in the 1960s. The Forbin Project, The Moon Is a Harsh

Mistress, and 2001: A Space Odyssey all tried to imagine our current future, but

missed the mark rather significantly. They all imagined huge machines that gained

sentience. What we have instead are impossibly small machines that are still … just

machines.{xx}

And there is one thing more about the software we have now, compared to the

software from back then: It’s made of the same stuff. It’s made of if statements,

assignment statements, and while loops.

Oh, you might object and say that we’ve got much better languages and superior

paradigms. After all, we program in Java, or C#, or Ruby, and we use object-oriented

design. True—and yet the code is still just an assemblage of sequence, selection, and

iteration, just as it was back in the 1960s and 1950s.

When you really look closely at the practice of programming computers, you realize

that very little has changed in 50 years. The languages have gotten a little better. The

tools have gotten fantastically better. But the basic building blocks of a computer

program have not changed.

剩余428页未读，继续阅读

dyj1992

粉丝: 0
资源: 4

清洁架构：程序员的软件结构与设计指南

CleanArchitecture:凌乱的清洁建筑

clean-architecture

Clean Architecture 干净的架构

clean architecture

go-clean-arch：基于阅读Bob叔叔的Clean Architecture的Go（Golang）Clean Architecture

node-clean-architecture:用 NodeJS 编写的 Clean Architecture 实现

rails-clean-architecture:Rails应用程序的Clean Architecture模板

clean_arc:Flutter Clean Architecture

clean-architecture:尝试通过遵循SOLID原理来展示Clean Architecture的原理

clean-architecture-structure:该脚本为Flutter应用程序创建Clean Architecture

Go-Clean-Architecture-REST-API:Golang Clean Architecture REST API示例

Android-Kotlin-Clean-Architecture：用Kotlin编写的Android Sample Clean Architecture App

Android-Clean-Architecture:这是一个示例电影列表Android应用程序，旨在演示Clean Architecture工具的使用。致力于所有Android开发人员-（Kotlin，MVVM，Clean Architecture，Rx-Java，Dagger，OkHttp，单元测试，SOLID原则，代码覆盖率）

test-driven-clean-architecture:测试驱动的Clean Architecture研讨会随附代码

flutter-tdd-clean-architecture:实施TDD和Clean Architecture的Flutter应用程序示例

clean architecture pdf

Clean.Architecture.2017.9.zip

Clean Architecture：软件架构与设计匠艺（英文版）

clean_architecture_app

最新资源