领域驱动设计：软件复杂性应对策略

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

《领域驱动设计：软件复杂性中心的应对策略》是埃里克·埃文斯（Eric Evans）所著的一本书，于2003年4月出版。该书针对软件开发中的复杂性问题，提出了一种名为领域驱动设计（Domain-Driven Design, DDD）的方法论。作者通过这本书探讨了如何在实际项目中运用领域模型来处理业务逻辑和系统架构，帮助开发者更好地理解和管理复杂的业务领域。首先，书中强调了领域模型的重要性。"Crunching Knowledge"章节中，作者提倡将业务知识转化为模型，使得开发者能够更深入地理解并表达业务的核心概念。埃文斯指出，通过普遍语言（ Ubiquitous Language）的创建，团队成员可以共享一致的理解，减少沟通障碍，这对于建立有效协作至关重要。 "Documents and Diagrams"部分展示了模型可视化工具的应用，通过文档和图表来清晰地展示模型结构，帮助团队成员更好地理解和遵循模型驱动的设计过程。同时，作者倡导模型与实现的分离（Binding Model and Implementation），即Model-Driven Design，让模型成为核心，确保业务逻辑独立于具体的技术实现。在"Letting the Bones Show; Why Models Matter to Users"中，埃文斯强调模型不仅对开发者有意义，而且直接影响到最终用户。模型应该直观反映业务流程，使用户能够理解并参与到设计过程中，从而提升用户体验。接着，书中介绍了构建模型驱动设计的基石。第四部分"Isolating the Domain"着重于分层架构（Layered Architecture），特别是区分域层（Domain Layer），这一层是模型的核心位置，用来存放业务规则和实体（Entities，通常作为引用对象）。此外，还提出了“智能UI反模式”（SMART UI Anti-Pattern），提醒开发者避免过度侵入领域模型的UI设计。第五部分探讨了如何在软件中表达模型，包括关联（Associations）、实体、值对象（Value Objects）、服务以及模块（Modules或Packages）的组织方式。这些元素构成了软件系统的基石，不同的模式有助于设计出灵活且易于维护的系统。第六部分聚焦于领域对象的生命周期管理，阐述了从概念到实现的完整流程，涵盖了设计、创建、修改和删除等各个阶段，以确保领域模型的稳定性和一致性。《领域驱动设计》是一本深入剖析软件开发领域核心问题的著作，它提供了一套方法论，帮助开发者有效地处理复杂性，创建与业务紧密耦合的高质量软件。通过阅读这本书，读者可以学习如何运用模型驱动设计原则，提高软件开发的效率和质量。

(Final Manuscript, April 15, 2003) © Eric Evans, 2003 15

1. Crunching Knowledge

A few years ago, I set out to design a specialized software tool for Printed Circuit Board (PCB) design. One

catch: I didn’t know anything about electronic hardware. I had access to some PCB designers, of course,

but they typically got my head spinning in three minutes. How was I going to understand enough to write

this software? I certainly wasn’t going to become an electrical engineer before the delivery deadline!

We tried the approach of having them tell me exactly what the software should do. Bad idea. They were

great circuit designers, but their software ideas usually involved reading in an ASCII file, sorting it, writing

it back out with some annotation and producing a report. This was clearly not going to lead to the leap

forward in productivity that they were looking for.

These first few meetings were discouraging, but there was a glimmer of hope in the reports they asked for.

They always involved “nets” and various details about them. A net, in this domain, is essentially a wire

conductor that can connect any number of components on a PCB and carry an electronic signal to

everything it is connected to. We had the first element of the domain model.

Net

Chip

Figure 1. 1

I started drawing diagrams for them as we discussed the things they wanted the software to do. I used an

informal variant of object interaction diagrams to walk through scenarios.

chip B

chip A

net

chip C

signal( )

signal()

Figure 1. 2

PCB EXPERT 1: The components wouldn’t have to be chips.

DEVELOPER (ME): So I should just call them components?

EXPERT 1: We call them “component instances”. There could be many of the same component.

EXPERT 2: The “net” box looks just like a component instance.

EXPERT 1: He’s not using our notation. Everything is a box for them, I guess.

DEVELOPER: Sorry to say, yes. I guess I’d better explain this notation a little more.

They constantly corrected me, and as they did I started to learn. We ironed out collisions and ambiguities in

their terminology and differences between their technical opinions, and they learned. They began to explain

things more precisely and consistently, and we started to develop a model together.

EXPERT 1: It isn’t enough to say a signal arrives at a ref-des, we have to know the pin.

DEVELOPER: Ref-des?

EXPERT 2: Same thing as a component instance. Ref-des is what it’s called in a particular tool we

use.

(Final Manuscript, April 15, 2003) © Eric Evans, 2003 18

And so it went (with much more stumbling than is shown here). Brainstorming and refining; questioning

and explaining. The model developed along with my understanding of the domain and their understanding

of how the model would play into the solution. A class diagram representing that early model looked

something like this.

signal(int)

Net

signal(int)

Component

Instance

pushes From Pin Number(int)

Component Type

Figure 1. 7

After a couple more part-time days of this, I felt I understood enough to attempt some code. I wrote a very

simple prototype, driven by an automated test framework. I avoided all infrastructure. There was no

persistence, and no U.I. This allowed me to concentrate on the behavior. I was able to demonstrate a simple

probe simulation in just a few more days. Although it used dummy data and wrote raw text to the console,

it was, none-the-less, doing the actual computation of path-lengths using Java objects. Those Java objects

reflected a model shared by the domain experts and myself.

The concreteness of this prototype made clearer to them what the model meant and how it related to the

functioning software. From that point, our model discussions became more interactive, as they could see

how I incorporated my newly acquired knowledge into the model and then into the software. And they had

concrete feedback from the prototype to evaluate their own thoughts.

Embedded in that model, which naturally became much more complicated that the one shown here, was

knowledge about the domain of PCB relevant to the problems we were solving. It consolidated many

synonyms and slight variations in descriptions. It excluded hundreds of facts that the engineers understood

but that were not directly relevant, such as the actual digital features of the components. A software

specialist like me could look at the diagrams and in minutes start to get a grip on what the software was

about. He or she would have a framework to organize new information and learn faster, to make better

guesses about what was important and what was not, and to communicate better with the PCB engineers.

As the engineers described new features they needed, I made them walk me through scenarios of

interactions of the objects. When the model objects couldn’t carry us through an important scenario, we

brainstormed new ones or changes to old ones crunched their knowledge. We refined the model; the code

coevolved. A few months later they had a rich tool that exceeded their expectations.

Why It Worked

Certain things we did led to this success.

1. Binding model and implementation as soon as possible. That crude prototype forged the essential

link.

2. Cultivating a language based on the model. At first, they had to explain elementary PCB issues to

me while I had to explain what a class diagram meant. But as the project proceeded, terms taken

straight out of the model, organized into sentences consistent with the structure of the model tested

the viability of the model immediately upon reaching their ears or mine.

3. Knowledge rich model. The objects had behavior and enforced rules. The model wasn’t just a data

schema, it was integral to solving a complex problem. It captured knowledge of various kinds.

(Final Manuscript, April 15, 2003) © Eric Evans, 2003 19

4. The model was distilled. Important concepts were added to the model as it became more complete,

but equally important, concepts were dropped when they didn’t prove useful or central. When na

unneeded concept was tied to one that was needed, a new model was found that distinguished the

essential concept so that the other could be dropped.

5. Knowledge crunching. The language combined with sketches and a brainstorming attitude turned

our discussions into laboratories of the model, in which hundreds of experimental variations could

be exercised, tried and judged.

It is this last point, knowledge crunching, that makes it possible to find a knowledge rich model and ways

to distill it. It requires the creativity of brainstorming and massive experimentation.

Financial analysts crunch numbers. They sift through reams of detailed figures, combining and

recombining them looking for the underlying meaning, looking for a simple presentation that brings out

what is really important – an understanding that can be the basis of a financial decision.

Effective domain modelers are knowledge crunchers. They take a torrent of information and probe for the

relevant trickle. They try one organizing idea after another, searching for the simple view that makes sense

of the mass. Many models are tried and rejected or transformed. Success comes in an emerging set of

abstract concepts that make sense of all the detail. This distillation is a rigorous expression of the particular

knowledge that has been found most relevant.

Knowledge crunching is not a solitary activity. A team of developers and domain experts collaborate,

typically led by developers. Together they draw in information and crunch it into a useful form. The raw

material comes from the minds of domain experts, from users of existing systems, from the prior

experience of the technical team with a related legacy system or another project in the same domain. It

comes in the form of documents written for the project or used in the business, and lots and lots of talk.

Early versions or prototypes feed experience back into the team and change earlier interpretations.

In the old waterfall method, the business experts talked to the analysts, analysts digested and abstracted and

passed the result along to the programmers who coded the software. This failed because it completely lacks

feedback. The analysts have full responsibility for creating the model based only on input from the business

experts. They have no opportunity to learn from the programmers or gain experience with early versions.

Knowledge trickles in one direction, but does not accumulate.

Other projects have iteration, but don’t build up knowledge because they don’t abstract. They get the

experts to describe a desired feature and they go build it. They show the experts the result and ask them

what to do next. If the programmers practice refactoring they can keep the software clean enough to

continue extending it, but if programmers are not interested in the domain, they only learn what the

application should do, not the principles behind it. Useful software can be built that way, but the project

will never gain the kind of leverage where powerful new features unfold as corollaries to older features.

Good programmers will naturally start to abstract and develop a model that can do more work. But when

this happens only in a technical setting, without collaboration with domain experts, the concepts are naïve.

That shallowness of knowledge produces software that does a basic job but lacks a deep connection to the

domain expert’s way of thinking.

The interaction between team members changes as all members crunch the model together. The constant

refinement of the domain model forces the developers to learn the important principles of the business they

are assisting, rather than mechanically producing functions. The domain experts often refine their own

understanding by being forced to distill what they know to essentials, and they come to understand the

conceptual rigor software projects require.

All this makes the team more competent knowledge crunchers. They winnow out the extraneous.

They recast the model into an ever more useful form. Because analysts and programmers are feeding

into it, it is cleanly organized and abstracted, and can provide leverage for the implementation.

剩余359页未读，继续阅读

weixin_43846993

粉丝: 0
资源: 1

领域驱动设计：软件复杂性应对策略

dddlib:DDD（域驱动设计）库，源于Eric Evans的书

Domain Driven Design in PHP.pdf

领域模型驱动设计domain driver design(PDF)

domain driven design

domain driven design distilled

Implementing Domain Driven Design

Domain driven design-quickly

Domain Driven Design with Spring Boot

Applying Domain Driven Design and Patterns

快速域驱动设计Domain Driven Design Quickly

最新资源