敏捷.NET环境下：领域驱动设计与模式实战指南

5星 · 超过95%的资源需积分: 34 136 浏览量更新于2024-07-23 4 收藏 4.34MB PDF 举报

"《运用领域驱动设计与模式：C#与.NET实例，第一版》是Jimmy Nilsson所著的一本专业书籍，针对.NET世界中的设计实践。该书强调了在敏捷开发方法的指导下，融合了企业模式社区的最佳实践。书中详细介绍了如何在.NET项目中应用诸如测试驱动开发（TDD）、对象关系映射（ORM）以及领域驱动设计（DDD）等关键技术，这些都是许多开发者认为未来软件开发的核心要素。作者将这些技术融入到实际项目中，强调随着技术的日益强大和复杂，理解并有效使用它们变得愈发重要。本书作为迈向更深入理解和实践的宝贵步骤，旨在帮助架构师和开发者构建强大、健壮且易于维护的系统。书中不仅理论深入，还提供了丰富的实例和案例，使读者能够在Microsoft.NET环境中充分利用这些设计和模式。 Martin Fowler，知名作者，他的著作如《重构》、《企业应用架构模式》和《领域驱动设计》等，都对本书的主题有着深远的影响。通过阅读《Applying Domain-Driven Design and Patterns》，读者不仅可以学习到最新的技术趋势，还能了解到如何在.NET平台上下文中整合和优化这些设计原则，从而提高软件项目的质量和可维护性。这本书是一份实用的指南，适合那些希望提升在.NET环境中进行现代软件开发技能的专业人士。"

Forewords

Building enterprise software is rarely easy. Although we have a plethora of tools and frameworks to

make it easier, we still have to figure out how to use these tools well. There are lots of approaches

you can take, but the trick is knowing which one to use in specific situationshardly ever does one

approach work in all cases. Over the last few years there's grown up a community of people looking

to capture approaches to design enterprise applications and document them in the form of patterns

(I keep an overview with links at http://martinfowler.com/articles/enterprisePatterns.html). People

involved in this effort, such as me, try to find common approaches and describe how to do them

well and when they are applicable. The resulting work is pretty wide ranging, and that can lead to

too much choice for the reader.

When I started writing Patterns of Enterprise Application Architecture (Addison-Wesley, 2002), I

looked for this kind of design advice in the Microsoft world. I struggled to find much of anything,

but one rare book that tackled the territory was Jimmy's earlier book. I liked his informal writing

style and eagerness to dig into concepts that many others skimmed over. So it's fitting that Jimmy

decided to take many of the ideas from me and the others in the enterprise patterns community

and show how you can apply them in writing .NET applications.

The focus of this enterprise patterns community is documenting good designs, but another thread

runs through us. We are also big fans of agile methods, embracing techniques such as Test-Driven

Development (TDD) and refactoring. So Jimmy also brought these ideas into this book. Many

people think that pattern-people's focus on design and TDD's focus on evolution are at odds. The

huge overlap between pattern-people and TDDers shows this isn't true, and Jimmy has weaved

both of these threads into this book.

The result is a book about design in the .NET world, driven in an agile manner and infused with the

products of the enterprise patterns community. It's a book that shows you how to begin applying

such things as TDD, object-relational mapping, and domain-driven design to .NET projects. If you

haven't yet come across these concepts, you'll find that this book is an introduction to techniques

that many developers think are the key for future software development. If you are familiar with

these ideas, the book will help you pass those ideas on to your colleagues.

Many people feel the Microsoft community has not been as good as others in propagating good

design advice for enterprise applications. As the technology becomes more capable and

sophisticated, it becomes more important to understand how to use it well. This book is a valuable

step in advancing that understanding.

Martin Fowler

http://martinfowler.com

The best way to learn how to do Domain-Driven Design (DDD) is to sit down next to a friendly,

patient, experienced practitioner and work through problems together, step-by-step. That is what

reading this book is like.

This book does not push a new grand scheme. It unaffectedly reports on one expert practitioner's

use of and combination of the current practices he has been drawn to.

Jimmy Nilsson reiterates what many of us have been saying: that several currently trendy

topicsspecifically, DDD, Patterns of Enterprise Application Architecture (PoEAA), and Test-Driven

Development (TDD)are not alternatives to each other, but are mutually reinforcing elements of

successful development.

Furthermore, all three of these are harder than they look at first. They require extensive knowledge

over a wide range. This book does spend some time advocating these approaches, but mostly it

focuses on the details of how to make them work.

Effective design is not just a bunch of techniques to be learned by rote; it is a way of thinking. As

Jimmy dives into an example he gives us a little window into his mind. He not only shows his

solution and explains it, he lets us see how he got there.

When I am designing something, dozens of considerations flit through my mind. If they are factors

I've dealt with often, they pass so quickly I am barely conscious of them. If they are in areas where

I have less confidence, I dwell on them more. I presume this is typical of designers, but it is

difficult to communicate to another person. As Jimmy walks through his examples, it is as if he

were slowing this process down to an observable pace. At every little juncture, three or four

alternatives present themselves and get weighed and rejected in favor of the one he eventually

chooses.

For example, we want model objects that are implemented free of entanglement with the

persistence technology. So what are eight ways (eight!) that a persistence framework can force you

to contaminate the implementation of a domain object? What considerations would lead you to

compromise on some of these points? What do the currently popular frameworks, including the

.NET platform, impose?

Jimmy thinks pragmatically. He draws on his experience to make a design choice that will likely

take him toward the goal, adhering to the deeper design principle, rather than the choice that looks

the most like a textbook example. And all of his decisions are provisional.

The first design principle Jimmy holds in front of himself is the fundamental goal of DDD: a design

that reflects deep understanding of the business problem at hand in a form that allows adaptation

to new wrinkles. So why so much discussion of technical framework and architecture?

It is a common misperception, perhaps a natural one, that such a priority on the domain demands

less technical talent and skill. Would that this were true. It would not be quite so difficult to become

a competent domain designer. Ironically, to render clear and useful domain concepts in software,

to keep them from being suffocated under technical clutter, requires particularly deft use of

technology. My observation is that those with the greatest mastery of technology and architectural

principles often know how to keep technology in its place and are among the most effective domain

modelers.

I do not refer to the knowledge of every quirk of complex tools, but to the mastery of the sort of

knowledge laid out in Martin Fowler's PoEAA, because naïve application of technology paradoxically

makes that technology more intrusive into the application.

For many people this book will fill in gaps of how to implement expressive object models in

practice. I picked up a number of useful ways of thinking through the application of technical

frameworks, and I especially firmed up my understanding of some particulars of doing DDD in a

.NET setting.

In addition to technical architecture, Jimmy spends a great deal of time on how to write tests. TDD

Preface: Bridging Gaps

On the cover of this book is a picture of the Øresund Bridge that connects Sweden and Denmark. It

seems that all software architecture books must have a bridge on the cover, but there are some

additional reasons the bridge is appropriate for this book.

This bridge replaced a ferry that I took many times as a child. I enjoy very much driving over it

even after dozens of times.

On a personal note, my father was on the team that built the highest parts of the bridge.

But beyond these, the main reason is that this book is very much about bridging gaps; bridging

gaps between users and developers; bridging gaps between business and software; bridging gaps

between logic and storage. Bridging gaps between "DB-guys" and "OO-guys"...

I will refrain from making a joke about the Bridge pattern [GoF Design Patterns]. Hey, how geeky

can a preface be?

Focus of This Book

The main focus of the book is how a Domain Model could be constructed to be clean, yet still be

persistence-friendly. It shows what the persistence solution could look like for such a Domain Model

and especially how to bridge that gap between the Domain Model and the database.

Put another way, my vision has been to provide a book that will put Eric Evans' Domain-Driven

Design [Evans DDD] and Martin Fowler's Patterns of Enterprise Application Architecture [Fowler

PoEAA] in context.

DDD might be perceived as a bit abstract. Therefore, more concrete examples are helpful regarding

persistence, for example. Mine may be fairly basic, but it is a platform to start from. This book not

only explains how to use the patterns, but also how the patterns are used in O/R Mappers, for

example.

It has become very clear to me that "one size does not fit all" when it comes to architecture. Having

said that, patterns have proven to be general enough to use and reuse in context after context.

The focus isn't on the patterns themselves, but this book uses patterns in every chapter as a tool

and language for discussing different design aspects. A nice side effect is that patterns-ignorant

readers will also gain some insight and interest into patterns along the way.

That also goes for TDD. Not all developers have become interested in this yet. I think it's especially

common in the .NET community that TDD (just as patterns) is considered a niche technique at best,

or it might even be totally unknown. Readers will learn how to apply TDD.

Why This Book?

Writing my first book [Nilsson NED] was a really tough project on top of all my other ordinary

projects and obligations. I was pretty sure I wouldn't write another, but the time came when I

thought I had something to say that I couldn't leave unsaid.

My change of heart started when I read two recent books that inspired me and changed my

thinking. First, there was Martin Fowler's Patterns of Enterprise Application Architecture [Fowler

PoEAA]. This book inspired me to give the Domain Model pattern another try after having failed

with several earlier attempts.

Then I read Eric Evans' book Domain-Driven Design [Evans DDD]. This book provided me with

insights about how to think and act regarding development with a strong domain focus and with a

certain style of how to apply the Domain Model pattern.

Another important influence was all that I learned from teaching my patterns course over a couple

of years. As I interacted with students and the material evolved, I had insights myself.

My views of DDD transformed as I worked on an ambitious (though unfortunately unfinished) open

source project called Valhalla, which I developed in collaboration with Christoffer Skjoldborg.

(Christoffer did by far the most work.)

To summarize all this, I felt that a book that dealt more with application than theory was needed,

but one that was based on solid ground, such as the DDD and PoEAA books. "Applying" feels close

to my heart because I consider myself a developer above anything else.

Target Audience

This book is aimed at a wide target audience. It will help if you have some knowledge of

Object-orientation

.NET or a similar platform

C# or a similar language

Relational databases; for example, SQL Server

However, interest and enthusiasm will compensate for any lack of prior experience.

I'd like to elaborate on my statement that the target audience is wide. First, we can think about the

way we put people into platform boxes. The book should serve .NET people who want a more core-

based approach than drag-till-you-drop (if I may use some weak generalizations). Java people

should get something out of the discussions and examples of how to combine DDD and O/R

Mapping.

I think the chosen language/platform is less and less important, so it feels a little strange to talk

about .NET people and Java people. Let's try to describe the target audience by using another

dimension. Then I think that the book is for developers, team leaders, and architects.

剩余612页未读，继续阅读

locigy

粉丝: 2
资源: 15

敏捷.NET环境下：领域驱动设计与模式实战指南

Applying Domain-Driven Design and Patterns: With Examples in C# and .NET

Applying Domain Driven Design and Patterns

领域驱动设计与模式实践.pdf

Domain-Driven Design Tackling Complexity in the Heart of Software(原版)

Applying.Domain.Driven.Design.and.Patterns.With.Examples.in.C.Sharp

Applying.Domain.Driven.Design

Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development (3rd Edition)

Domain Driven Design

Entity Framework Core in Action-原版

The Role of MATLAB in Nonlinear Control System Design: Challenges and Opportunities

最新资源