掌握领域驱动设计：从零到精通的旅程

4星 · 超过85%的资源需积分: 49 135 浏览量更新于2024-07-19 1 收藏 4.49MB PDF 举报

"《领域驱动设计》(Domain Driven Design, DDD) 是Eric Evans所著的一本经典书籍，旨在解决软件开发中业务与技术之间存在的断裂问题。作者在第一章中讲述了一个关于设计电路板软件工具的挑战，他意识到作为一个对电子硬件几乎一无所知的软件开发者，传统的面向对象设计方法不足以满足复杂且专业化的硬件需求。在设计过程中，作者认识到仅仅依赖于面向对象编程(OOP)的语言和技术是不够的，因为业务逻辑往往需要更深入的理解和表达。DDD的核心理念是通过将业务知识嵌入到软件设计中，而非仅仅关注技术实现。它提倡建立一个由领域模型(Domain Model)主导的设计过程，其中每个领域对象(Domain Object)代表业务实体，领域术语(Universal Language)成为沟通业务逻辑的共同语言。在第一章中，作者遇到的关键概念是"网络"(Nets)，这是电路板设计中的基本元素，代表可以连接多个组件并传输电信号的物理路径。这标志着在设计软件时，作者开始尝试将业务领域的核心概念转化为可编程的对象。通过深入了解并抽象出这些领域概念，他开始遵循DDD的原则，如SOLID原则和设计模式，以及如何运用UML图来可视化领域模型，从而更好地理解和表达业务需求。 DDD并不是万能的解决方案，其适用性取决于具体场景。然而，它强调的是工程能力与业务理解的结合，要求开发者跳出纯粹的技术框架，深入思考业务流程和用户需求。通过实践DDD，作者期望提高代码的可读性和可维护性，让其他开发者能够更快地理解和扩展软件。总结来说，《领域驱动设计》是一本帮助开发者将业务逻辑与技术实现紧密结合的指南，通过深入理解业务领域，用更符合业务逻辑的方式来编写代码，从而提高软件的质量和效率。阅读这本书，对于提升业务敏感度和工程能力，特别是对那些希望在技术热点如云计算、深度学习等领域取得突破的工程师来说，具有重要的价值。"

Scenario 2: Domain Model Enriched to Support Discussion

User: So when we change the customs clearance point, we need to redo the whole routing plan.

Developer: Right. When you change any of the attributes in the Route Specification, we'll delete

the old Itinerary and ask the Routing Service to generate a new one based on the new Route Spec-

ification.

User: If we hadn't specified a customs clearance point at all before, we'll have to do that at the same

time.

Developer: Sure, anytime you change anything in the Route Spec, we'll regenerate the Itinerary.

That includes entering something for the first time.

User: Of course, if the old customs clearance just happened to be the right one, we wouldn't want

to do that.

Developer: Oh, no problem. It's easier to just make the Routing Service redo the Itinerary every

time.

User: Yes, but it's extra work for us to make all the supporting plans for a new Itinerary, so we don't

want to reroute unless the change necessitates it.

Developer: Oh. Then we'll have to add some functionality to the Route Specification. Then, when-

ever you change anything in the Spec, we'll see if the Itinerary still satisfies the Specification. If it

doesn't, we'll have the Routing Service regenerate the Itinerary.

User: You won't have to worry about this on origin or destination, since the Itinerary would always

change then.

Developer: Fine, but it will be simpler for us to just do the comparison every time. The Itinerary will

only be generated when the Route Specification is no longer satisfied.

The second dialog conveys more of the intent of the domain expert. The user employed the word

“itinerary” in both dialogs, but in the second it was an object the two could discuss precisely, con-

cretely. They discussed the “route specification” explicitly, instead of describing it each time in terms

of attributes and procedures.

These two dialogs were deliberately constructed to closely parallel each other. Realistically, the first

would have been more verbose, bloated with explanations of application features and miscommu-

nications. The domain-model-based terminology of the second design makes the second dialog

more concise.

Communication and the Use of Language 18

Modeling Out Loud

The detachment of speech from other forms of communication is a particularly great loss because

we humans have a genius for spoken language. Unfortunately, when people speak, they usually

don't use the language of the domain model.

That statement may not ring true for you initially, and indeed there are exceptions. But the next time

you attend a requirements or design discussion, really listen. You'll hear descriptions of features in

business jargon or layman's versions of the jargon. You'll hear talk about technical artifacts and

concrete functionality. Sure, you'll hear terms from the domain model; obvious nouns in the common

language from the business jargon will typically be coded as objects, and so those terms will tend

to be mentioned. But do you hear phrases that could even remotely be described in terms of rela-

tionships and interactions in your current domain model?

One of the best ways to refine a model is to explore with speech, trying out loud various constructs

from possible model variations. Rough edges are easy to hear.

“If we give the Routing Service an origin, destination, and arrival time, it can look up the stops

the cargo will have to make and, well . . . stick them in the database.” (

vague and technical

)

“The origin, destination, and so on . . . it all feeds into the Routing Service, and we get back an

Itinerary that has everything we need in it.” (

more complete, but verbose

)

“A Routing Service finds an Itinerary that satisfies a Route Specification.” (

concise

)

It is vital that we play around with words and phrases, harnessing our linguistic abilities to the mod-

eling effort, just as it is vital to engage our visual/spatial reasoning by sketching diagrams. Just as

we employ our analytical abilities with methodical analysis and design, and that mysterious “feel” of

the code. These ways of thinking complement each other, and it takes all of them to find useful

models and designs. Of all of these, experimenting with language is most often overlooked. (Part

III of this book will delve into this discovery process and show this interplay in several dialogs.)

In fact, our brains seem to be somewhat specialized for dealing with complexity in spoken language

(one good treatment for laymen, like myself, is

The Language Instinct

, by Steven Pinker [Pinker

1994]). For example, when people of different language backgrounds come together for commerce,

if they don't have a common language they invent one, called a

pidgin

. The pidgin is not as com-

prehensive as the speakers' original languages, but it is suited to the task at hand. When people

are talking, they naturally discover differences in interpretation and the meaning of their words, and

they naturally resolve those differences. They find rough spots in the language and smooth them out.

Once I took an intensive Spanish class in college. The rule in the classroom was that not a word of

English could be spoken. At first, it was frustrating. It felt very unnatural, and required a lot of self-

discipline. But eventually my classmates and I broke through to a level of fluency that we could never

have reached through exercises on paper.

As we use the

UBIQUITOUS LANGUAGE

of the domain model in discussions—especially discus-

sions in which developers and domain experts hash out scenarios and requirements—we become

more fluent in the language and teach each other its nuances. We naturally come to share the

language that we speak in a way that never happens with diagrams and documents.

Bringing about a

UBIQUITOUS LANGUAGE

on a software project is easier said than done, and we

have to fully employ our natural talents to pull it off. Just as humans' visual and spatial capabilities

let us convey and process information rapidly in graphical overviews, we can exploit our innate talent

for grammatical, meaningful language to drive model development.

Therefore, as an addendum to the

UBIQUITOUS LANGUAGE

pattern:

Play with the model as you talk about the system. Describe scenarios out loud using the elements

and interactions of the model, combining concepts in ways allowed by the model. Find easier ways

to say what you need to say, and then take those new ideas back down to the diagrams and code.

Communication and the Use of Language 19

One Team, One Language

Technical people often feel the need to “shield” the business experts from the domain model. They

say:

“Too abstract for them.”

“They don't understand objects.”

“We have to collect requirements in their terminology.”

These are just a few of the reasons I've heard for having two languages on the team. Forget them.

Of course there are technical components of the design that may not concern the domain experts,

but the core of the model had better interest them. Too abstract? Then how do you know the ab-

stractions are sound? Do you understand the domain as deeply as they do? Sometimes specific

requirements are collected from lower-level users, and a subset of the more concrete terminology

may be needed for them, but a domain expert is assumed to be capable of thinking somewhat deeply

about his or her field.

If sophisticated domain experts don't understand the model, there is something

wrong with the model.

Now at the beginning, when the users are discussing future capabilities of the system that haven't

been modeled yet, there is no model for them to use. But as soon as they begin to work through

these new ideas with the developers, the process of groping toward a shared model begins. It may

start out awkward and incomplete, but it will gradually get refined. As the new language evolves,

the domain experts must make the extra effort to adopt it, and to retrofit any old documents that are

still important.

When domain experts use this

LANGUAGE

in discussions with developers or among themselves,

they quickly discover areas where the model is inadequate for their needs or seems wrong to them.

The domain experts (with the help of the developers) will also find areas where the precision of the

model-based language exposes contradictions or vagueness in their thinking.

The developers and domain experts can informally test the model by walking through scenarios,

using the model objects step-by-step. Almost every discussion is an opportunity for the developers

and user experts to play with the model together, deepening each other's understanding and refining

concepts as they go.

The domain experts can use the language of the model in writing use cases, and can work even

more directly with the model by specifying acceptance tests.

Objections are sometimes raised to the idea of using the language of the model to collect require-

ments. After all, shouldn't requirements be independent of the design that fulfills them? This over-

looks the reality that all language is based on some model. The meanings of words are slippery

things. The domain model will typically derive from the domain experts' own jargon but will have

been “cleaned up,” to have sharper, narrower definitions. Of course, the domain experts should

object if these definitions diverge from the meanings accepted in the field. In an Agile process,

requirements evolve as a project goes along because hardly ever does the knowledge exist up front

to specify an application adequately. Part of this evolution should be the reframing of the require-

ments in the refined

UBIQUITOUS LANGUAGE

Multiplicity of languages is often necessary, but the linguistic division should never be between the

domain experts and the developers. (Chapter 12, “Maintaining Model Integrity,” deals with the co-

existence of models on the same project.)

Communication and the Use of Language 20

Of course, developers do use technical terminology that a domain expert wouldn't understand. De-

velopers have an extensive jargon that they need to discuss the technical aspects of a system.

Almost certainly, the users will also have specialized jargon that goes well beyond the narrow scope

of the application and the understanding of the developers. But these are

extensions

to the lan-

guage. These dialects should not contain alternative vocabularies for the same domain that reflect

distinct models.

Figure 2.3. UBIQUITOUS LANGUAGE is cultivated in the intersection of jargons.

With a

UBIQUITOUS LANGUAGE

, conversations among developers, discussions among domain

experts, and expressions in the code itself are all based on the same language, derived from a

shared domain model.

Documents and Diagrams

Whenever I'm in a meeting discussing a software design, I can hardly function without drawing on

a whiteboard or sketchpad. A good part of what I draw is UML diagrams, mostly class diagrams or

object-interactions.

Some people are naturally visual, and diagrams help people grasp certain kinds of information. UML

diagrams are pretty good at communicating relationships between objects, and they are fair at

showing interactions. But they do not convey the conceptual definitions of those objects. In a meet-

ing, I would flesh out those meanings in speech as I sketched the diagram, or they would emerge

in a dialog with other participants.

Simple, informal UML diagrams can anchor a discussion. Sketch a diagram of three to five objects

central to the issue at hand, and everyone can stay focused. Everyone will share a view of the

relationships between the objects and, significantly, the objects' names. The spoken discussion can

be more effective with this aid. A diagram can be changed as people try different thought experi-

ments, and the sketch will take on some of the fluidity of spoken words, a true part of the discussion.

After all, UML stands for Unified Modeling

Language

The trouble comes when people feel compelled to convey the whole model or design through UML.

A lot of object model diagrams are too complete and, simultaneously, leave too much out. They are

too complete because people feel they have to put all the objects that they are going to code into a

modeling tool. With all that detail, no one can see the forest for the trees.

Communication and the Use of Language 21

Yet in spite of all that detail, the attributes and relationships are only half the story of an object model.

The behavior of those objects and the constraints on them are not so easily illustrated. Object in-

teraction diagrams can illustrate some tricky hotspots in the design, but the bulk of the interactions

can't be shown that way. It is just too much work, both to create the diagrams and to read them.

And an interaction diagram can still only imply the purpose behind the model. To include constraints

and assertions, UML falls back on text, placed in little brackets, inserted into the diagram.

The behavioral responsibilities of an object can be hinted at through operation names, and they can

be implicitly demonstrated with object interaction (or sequence) diagrams, but they cannot be

sta-

ted

. So, this task falls to supplemental text or conversation. In other words, a UML diagram cannot

convey two of the most important aspects of a model: the meaning of the concepts it represents,

and what the objects are meant to do. This needn't trouble us, though, because careful use of English

(or Spanish, or whatever) can fill this role pretty well.

Nor is UML a very satisfying programming language. Every attempt I've seen to use the code-

generation capabilities of the modeling tools has been counterproductive. If you are constrained by

the capabilities of UML, you will often have to leave out the most crucial part of the model because

it is some rule that doesn't fit into a box-and-line diagram. And, of course, a code generator cannot

make use of those textual annotations. If you do use some technology that allows executable pro-

grams to be written in a UML-like diagramming language, then the UML diagram is reduced to merely

another way to view the program itself, and the very meaning of “model” is lost. If you use UML as

your implementation language, you will still need other means of communicating the uncluttered

model.

Diagrams are a means of communication and explanation, and they facilitate brainstorming. They

serve these ends best if they are minimal. Comprehensive diagrams of the entire object model fail

to communicate or explain; they overwhelm the reader with detail and they lack meaning. This leads

us away from the all-encompassing object model diagram, or even the all-encompassing database

repository of UML. It leads us toward simplified diagrams of conceptually important parts of the

object model that are essential to understanding the design. The diagrams in this book are typical

of those I use on projects. They simplify, they explain, and they even incorporate a bit of nonstandard

notation when it clarifies their point. They show design constraints, but they are not design specifi-

cations in every detail. They represent the skeletons of ideas.

The vital detail about the design is captured in the code

. A well-written implementation should be

transparent, revealing the model underlying it. (Making sure that this happens is the subject of the

next chapter and much of the rest of this book.) Supplemental diagrams and documents can guide

people's attention to the central points. Natural language discussion can fill in the nuances of mean-

ing. This is why I prefer to turn things inside out from the way a typical UML diagram handles them.

Rather than a diagram annotated with text, I write a text document illustrated with selective and

simplified diagrams.

Always remember that

the model is not the diagram

. The diagram's purpose is to help communicate

and explain the model. The code can serve as a repository of the details of the design. Well-written

Java is as expressive as UML in its way. Carefully selected and constructed diagrams can serve to

focus attention and aid navigation if they are not obscured by a compulsion to represent the model

or design completely.

Written Design Documents

Spoken communication supplements the code's rigor and detail with meaning. But although talking

is critical to connecting everyone to the model, a group of any size will probably need the stability

and share-ability of some written documents. But making written documents that actually help the

team produce good software is a challenge.

Once a document takes on a persistent form, it often loses its connection with the flow of the project.

It is left behind by the evolution of the code, or by the evolution of the language of the project.

Communication and the Use of Language 22

剩余323页未读，继续阅读

张建飞（Frank）

粉丝: 6215
资源: 10

掌握领域驱动设计：从零到精通的旅程

Implementing Domain-Driven Design epub

领域驱动设计(DomainDrivenDesign)参考架构详解

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

domain driven design

patterns, principles, and practices of domain-driven design mobi pdf

Attribute-Driven Design

ADD(Attribute-Driven Design)过程

属性驱动设计Attribute-Driven Design

属性驱动设计(Attribute-Driven Design的步骤是什么

推荐几本提高代码质量的书籍

最新资源