Clean Architecture：推荐指南

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

《Clean Architecture》是一本在IT领域备受推崇的书籍，它深入探讨了软件架构设计的最佳实践。本书主要关注的是如何构建清晰、模块化和可维护的系统架构，以实现系统的高内聚低耦合，从而提高系统的灵活性和稳定性。作者可能强调了SOLID原则、分层架构（如模型-视图-控制器，Model-View-Controller，MVC）、以及依赖倒置原则等核心概念，这些原则有助于设计出易于测试、扩展和替换的系统。 Clean Architecture的设计理念主张将应用程序划分为几个关键层次，包括表示层（Presentation Layer）、应用服务层（Application Services）、基础设施层（Infrastructure）以及领域层（Domain）。这样做的好处在于： 1. **分层设计**：每一层都有明确的责任和边界，避免了不同模块间的混乱，提高了代码的可读性和可维护性。 2. **独立性**：通过高内聚低耦合的设计，每个层次都能独立于其他层次进行开发和修改，降低了对其他部分的依赖，便于团队协作。 3. **解耦**：基础设施层通常处理与具体技术实现相关的细节，如数据库访问、网络通信等，这使得应用能更容易地切换到不同的技术栈。 4. **可测试性**：由于各层之间的职责明确，单元测试和集成测试变得更加容易，有利于持续集成和持续部署。 5. **适应性**：随着业务需求的变化，只需调整应用服务层和领域层，而不会影响底层基础设施或表示层。关于EPUB格式的电子书，虽然它是一种开放标准，但在不同阅读设备和应用上支持程度不一。为了获得最佳阅读体验，建议读者根据自己的设备特性进行个性化设置，如字体大小、单双列模式、横竖屏切换，以及代码展示方式。书中编程代码和配置示例通常以单列和横版模式呈现，并提供点击链接查看高清代码图片选项，以便读者能够准确地理解源代码布局。《Clean Architecture》是一本关于软件设计原则和实践的实用指南，适合任何寻求提升软件架构能力的开发者阅读，无论是初学者还是经验丰富的专业人员，都能从中获益匪浅。

FOREWORD

What do we talk about when we talk about architecture?

As with any metaphor, describing software through the lens of architecture

can hide as much as it can reveal. It can both promise more than it can deliver

and deliver more than it promises.

The obvious appeal of architecture is structure, and structure is something

that dominates the paradigms and discussions of software development—

components, classes, functions, modules, layers, and services, micro or

macro. But the gross structure of so many software systems often defies

either belief or understanding—Enterprise Soviet schemes destined for

legacy, improbable Jenga towers reaching toward the cloud, archaeological

layers buried in a big-ball-of-mud slide. It’s not obvious that software

structure obeys our intuition the way building structure does.

Buildings have an obvious physical structure, whether rooted in stone or

concrete, whether arching high or sprawling wide, whether large or small,

whether magnificent or mundane. Their structures have little choice but to

respect the physics of gravity and their materials. On the other hand—except

in its sense of seriousness—software has little time for gravity. And what is

software made of? Unlike buildings, which may be made of bricks, concrete,

wood, steel, and glass, software is made of software. Large software

constructs are made from smaller software components, which are in turn

made of smaller software components still, and so on. It’s coding turtles all

the way down.

When we talk about software architecture, software is recursive and fractal in

nature, etched and sketched in code. Everything is details. Interlocking levels

of detail also contribute to a building’s architecture, but it doesn’t make sense

to talk about physical scale in software. Software has structure—many

structures and many kinds 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

剩余461页未读，继续阅读

trenhui

粉丝: 3
资源: 5

Clean Architecture：推荐指南

CleanArchitecture

Clean Architecture - Robert C. Martin，英文版，mobi格式，适合kindle和电脑看。官方epub转换

The Clean Architecture in PHP 无水印原版pdf

clean architecture

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

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

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

clean_arc:Flutter Clean Architecture

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

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

最新资源