洁净架构：罗伯特·马丁的实用软件设计法则

PDF文件

Software

Archite

Robert

Martin

3星 · 超过75%的资源 | 下载需积分: 9 | 8.22MB | 更新于2024-07-17 | 38 浏览量 | 举报收藏

立即下载

《清洁架构》是一本由传奇软件开发大师罗伯特·C·马丁（亦被称为“Uncle Bob”）所著的实践性软件架构解决方案书籍。该书的核心概念是Clean Architecture，它提倡将稳定的业务规则（高层抽象）与易变的技术细节（底层细节）分离，通过清晰地定义界限来实现系统的稳健设计。马丁强调，通过应用通用的软件架构原则，可以在软件系统全生命周期中显著提升开发人员的生产力。在书中，马丁阐述了如何构建一个可维护且可扩展的架构，其中关键包括以下几点： 1. **分层结构**：Clean Architecture主张将软件分为几个层次，如界面层、应用层、领域层、基础设施层等，每一层都有明确的责任。这样做的目的是确保高层逻辑不受底层实现的影响，从而降低技术债务。 2. **边界划分**：马丁强调，确保业务逻辑（领域模型）与具体的技术实现（数据访问、数据库、API等）之间有清晰的边界，这有助于保持系统灵活性并易于重构。 3. **独立的业务规则**：业务规则应尽可能地独立于技术细节，使它们可以在不同技术栈中重用，减少对特定技术的依赖。 4. **原则驱动**：遵循一系列通用的软件架构原则，如单一职责原则、开闭原则等，有助于设计出健壮和可扩展的系统。 5. **适应变化**：通过这样的架构，系统能够应对技术栈的变更，而不会对核心业务逻辑造成太大影响，提高了应对未来需求的能力。 6. **代码呈现优化**：书中可能包含编程代码和配置示例，为了最佳阅读体验，建议读者在单列模式和横屏模式下调整字体大小，或者点击链接查看高质量的代码图片，以便获得与印刷版一致的视觉效果。阅读这本书，开发者可以学习到如何在实际项目中实施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页未读，继续阅读

weixin_44406522

粉丝: 0

洁净架构：罗伯特·马丁的实用软件设计法则

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-structure:该脚本为Flutter应用程序创建Clean Architecture

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

最新资源