掌握领域驱动设计：连接软件架构与商业战略

需积分: 13 143 浏览量更新于2024-06-29 收藏 19.39MB PDF 举报

"《学习领域驱动设计》(Learning Domain-Driven Design: Aligning Software Architecture and Business Strategy)是由Vlad Khononov所著，由O'Reilly Media于2021年出版的一本专业书籍。该书旨在帮助读者深入了解和掌握领域驱动设计（Domain-Driven Design, DDD）这一软件开发方法论，它强调将软件架构与商业策略紧密结合。在书中，作者Vlad Khononov以其丰富的实践经验为基础，分享了如何将DDD应用于解决实际商业问题的方法。他的独特视角和深入洞察使得本书不仅适合初学者，也对有经验的DDD实践者具有启发性。前言部分由Julie Lerman撰写，她高度评价了Vlad的思维方式，认为他的理念不断推动着DDD社区的发展，并肯定了这本书对于理解和实践DDD的价值。评论家们一致赞赏这本书，如技术顾问Nick Tune表示，阅读过程中，他发现这本书名副其实，是一本既引人入胜又充满信息量的实践指南。书中涵盖了从战略规划到技术设计的全方位内容，无论是对已有深入理解的领域，还是对于概念和实践了解较少的部分，都能提供新的见解和深化理解。架构咨询师Ruth Malan提到，她在阅读过程中受益匪浅，不仅在熟悉的领域有所深化，而且在接触较少的领域也收获了宝贵的新知识，她称赞Vlad是个出色的老师。 Vlad的丰富实战经验来自于处理复杂项目，他在书中以一种独特的方式讲述DDD的故事，为学习者提供了宝贵的学习视角和实践指导。这本著作不仅传授理论，还结合了实际案例，使得读者能够更好地理解和应用DDD原则，从而提升软件开发的效率和业务价值的契合度。《学习领域驱动设计》是一本不可或缺的参考书，对于任何希望在软件开发中实现业务和技术深度结合的专业人士来说，无论是初次涉猎还是寻求进阶，都将从中获得宝贵的洞见和实用技能。"

encouraged the community to continue to evolve DDD—not only its practices but in

finding ways to more effectively share its ideas.

And this brings me to why I am such a fan of Learning Domain-Driven Design. I was

already a fan of Vlad through his conference speaking and other writings. He has a

lot of hard-won experience as a DDD practitioner working on some deeply complex

projects and has been generous in sharing that knowledge. In this book, he tells the

“story” of DDD (not its history, but its concepts) in a unique way, providing a great

perspective for learning. This book is aimed at newcomers, yet as a longtime DDD

practitioner who also writes and speaks about DDD, I found that I learned so much

from his perspective. I was eager to reference his book in my DDD Fundamentals

course on Pluralsight before the book was even published and have already been

sharing some of this perspective in conversations with clients.

Getting started with DDD can be confusing. Just as we use DDD to reduce the com‐

plexity of projects, Vlad presents DDD in a way that reduces the complexity of the

topic itself. And he does more than explain the principles of DDD. The latter portion

of the book shares some important practices that have evolved from DDD, such as

EventStorming, addresses the problem of evolving the business focus or organization

and how this might affect the software, and discusses how DDD aligns with microser‐

vices and how you can integrate it with a slew of well-known software patterns. I

think Learning Domain-Driven Design will be an excellent introduction to DDD for

newcomers, and a very worthy read for experienced practitioners as well.

— Julie Lerman

Soware Coach, O’Reilly Author,

and Serial DDD Advocate

xiv | Foreword

another three years to understand the wisdom Eric shared. The book is very

advanced, and the fact that English is my third language didn’t help.

Eventually, though, everything fell into place, and I made peace with the domain-

driven design (DDD) methodology. I learned the principles and patterns of DDD, the

intricacies of modeling and implementing the business logic, and how to tackle the

complexity in the heart of the software that I was building. Despite the obstacles, it

definitely was worth it. Getting into domain-driven design was a career-changing

experience for me.

Why I Wrote This Book

Over the past 10 years, I have introduced domain-driven design to my colleagues at

different companies, conducted in-person classes, and taught online courses. The

teaching perspective not only helped me deepen my knowledge, but also allowed me

to optimize the way I explain the principles and patterns of domain-driven design.

As often happens, teaching is even more challenging than learning. I’m a huge fan of

Eliyahu M. Goldratt’s work and teachings. Eliyahu used to say that even the most

complex systems are inherently simple when viewed from the right angle. During my

years of teaching DDD, I was looking for a model of the methodology that would

uncover the inherent simplicity of domain-driven design.

This book is the result of my efforts. Its goal is to democratize domain-driven design;

make it easier to understand and more accessible to employ. I believe that the DDD

methodology is absolutely invaluable, especially when designing modern software

systems. This book will give you just enough tools to start applying domain-driven

design in your day-to-day work.

Who Should Read This Book

I believe that knowledge of domain-driven design principles and patterns will be use‐

ful for software engineers at all levels: junior, senior, staff, and principal. Not only

does DDD provide tools and techniques for modeling and effectively implementing

software, it also illuminates an often-overlooked aspect of software engineering: the

context. Equipped with the knowledge of the system’s business problem, you will be

much more effective at choosing the appropriate solution. A solution that is not

under- or over-engineered, but addresses business needs and goals.

Domain-driven design is even more important for software architects, and even more

so for aspiring software architects. Its strategic design decision tools will help you

decompose a large system into components—services, microservices, or

subsystems—and design how the components are integrated with one another to

form a system.

xvi | Preface

Ultimately, in this book we will discuss not only how to design software, but also how

to co-evolve the design with changes in its business context. That crucial aspect of

software engineering will help you keep the system’s design “in shape” over time and

prevent its degradation into a big ball of mud.

Navigating the Book

This book is divided into four parts: strategic design, tactical design, DDD in practice,

and DDD’s relationships to other methodologies and patterns. In Part I, we cover

tools and techniques for making large-scale software design decisions. In Part II, we

focus on the code: the different ways to implement a system’s business logic. Part III

discusses techniques and strategies for applying DDD in real-life projects. Part IV

continues the discussion of domain-driven design, but this time in the context of

other methodologies and patterns.

Here is a short summary of what you will find in each chapter:

• Chapter 1 establishes the context of a software engineering project: the business

domain, its goals, and how the software is intended to support them.

• Chapter 2 introduces the notion of a “ubiquitous language”: domain-driven

design’s practice for effective communication and knowledge sharing.

• Chapter 3 discusses how to tackle the complexity of business domains and design

the system’s high-level architectural components: bounded contexts.

• Chapter 4 explores the different patterns of organizing the communication and

integration between the bounded contexts.

• Chapter 5 starts the discussion of business logic implementation patterns with

two patterns addressing the cases of simple business logic.

•

Chapter 6 advances from simple to complex business logic and introduces the

domain model pattern for tackling its complexity.

• Chapter 7 adds the perspective of time and introduces an even more advanced

way to model and implement business logic: the event-sourced domain model.

• Chapter 8 shifts the focus to a higher level and describes three architectural pat‐

terns for structuring components.

• Chapter 9 provides the patterns needed to orchestrate the work of the system’s

components.

• Chapter 10 ties together the patterns discussed in the earlier chapters into a num‐

ber of simple rules of thumb that streamline the process of making design

decisions.

• Chapter 11 explores software design from the perspective of time and how it is

supposed to change and evolve through its lifespan.

Preface | xvii

• Chapter 12 introduces EventStorming: a low-tech workshop for effectively shar‐

ing knowledge, building shared understanding, and designing software.

• Chapter 13 addresses the difficulties you may face when introducing domain-

driven design to brownfield projects.

• Chapter 14 discusses the relationship between the microservices architectural

style and domain-driven design: where they differ and where they complement

each other.

• Chapter 15 explores domain-driven design patterns and tools in the context of

the event-driven architecture.

•

Chapter 16 shifts the discussion from operational systems to analytical data man‐

agement systems and discusses the interplay between domain-driven design and

the data mesh architecture.

All of these chapters end with a number of exercise questions to reinforce the learn‐

ing. Some of the questions use the fictional company “WolfDesk” to demonstrate the

various aspects of domain-driven design. Please read the following description of

WolfDesk, and return to it when you answer relevant exercise questions.

Example Domain: WolfDesk

WolfDesk provides a help desk tickets management system as a service. If your start-

up company needs to provide support to your customers, with WolfDesk’s solution

you can get up and running in no time.

WolfDesk uses a different payment model than its competitors. Instead of charging a

fee per user, it allows the tenants to set up as many users as needed, and the tenants

are charged for the number of support tickets opened per charging period. There is

no minimum fee, and there are automatic volume discounts for certain thresholds of

monthly tickets: 10% for opening more than 500 tickets, 20% for opening more than

750 tickets, and 30% for opening more than 1,000 tickets per month.

To prevent tenants from abusing the business model, WolfDesk’s ticket lifecycle algo‐

rithm ensures that inactive tickets are closed automatically, encouraging customers to

open new tickets when further support is needed. Moreover, WolfDesk implements a

fraud detection system that analyzes messages and detects cases of unrelated topics

being discussed in the same ticket.

To help its tenants streamline the support-related work, WolfDesk has implemented a

“support autopilot” feature. The autopilot analyzes new tickets and tries to automati‐

cally find a matching solution from the tenant’s ticket history. The functionality

allows for further reducing the tickets’ lifespans, encouraging customers to open new

tickets for further questions.

xviii | Preface

剩余339页未读，继续阅读

euafam

粉丝: 0
资源: 4

掌握领域驱动设计：连接软件架构与商业战略

Domain-driven Design

Domain-Driven Design

Domain Driven Design

JavaScript Domain-Driven Design(PACKT,2015)

Multilayer Perceptrons (MLP) in Finance: Applications and Cases, Data-Driven Financial Decision-...

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

人工智能-机器学习-某24GHz移动终端天线的分析及其优化应用.pdf

Handbook of Research on Soft Computing and Nature-Inspired Algorithms

study-path:关于干净代码，测试驱动开发，旧版代码，重构，域驱动设计和微服务架构的有组织的学习路径

JavaEE项目中的领域驱动设计实践与E-Learning网站开发

最新资源