在TDD和BDD中，你/团队最关注的是系统的测试和行为，而不是代码实现。

类似地，当系统分析师、产品负责人、开发团队，当然还有代码实体/类、变量、函数、用户界面流程使用相同的语言进行交流时，它被称为领域驱动设计

DDD是一个思维过程。在软件设计建模时，您需要将业务领域/流程置于关注的中心，而不是数据结构、数据流、技术、内部和外部依赖关系。

使用DDD建模系统的方法有很多

事件来源(使用事件作为唯一的真相来源) 关系数据库 图形数据库 使用函数式语言

域对象:

用非常朴素的话来说，一个物体

名称是否基于业务流程/流 完全控制其内部状态，即公开方法来操作状态。 始终在使用上下文中满足所有业务不变量/业务规则。 遵循单一责任原则

只有理解了以下内容，你才能理解领域驱动设计:

What is a domain? The field for which a system is built. Airport management, insurance sales, coffee shops, orbital flight, you name it. It's not unusual for an application to span several different domains. For example, an online retail system might be working in the domains of shipping (picking appropriate ways to deliver, depending on items and destination), pricing (including promotions and user-specific pricing by, say, location), and recommendations (calculating related products by purchase history). What is a model? "A useful approximation to the problem at hand." -- Gerry Sussman An Employee class is not a real employee. It models a real employee. We know that the model does not capture everything about real employees, and that's not the point of it. It's only meant to capture what we are interested in for the current context. Different domains may be interested in different ways to model the same thing. For example, the salary department and the human resources department may model employees in different ways. What is a domain model? A model for a domain. What is Domain-Driven Design (DDD)? It is a development approach that deeply values the domain model and connects it to the implementation. DDD was coined and initially developed by Eric Evans.

从这里被剔除

编辑:

因为这似乎是谷歌上的一个顶级结果，而我下面的答案不是，请参考这个更好的答案:

https://stackoverflow.com/a/1222488/1240557

旧答案(不太完整:))

为了创建好的软件，你必须知道这个软件是什么 都是关于。您不能创建一个银行软件系统，除非您 有一个很好的理解银行业是关于什么的，一个人必须 了解银行领域。

摘自:Eric Evans的领域驱动设计。

这本书很好地描述了DDD。

注册下载这本书的摘要。

使组织对问题领域有广泛的理解 为每个子问题领域开发一种普遍存在的语言(一种共同的思维模式)。 在解决方案域(代码)中尽可能使用该语言。 只有选择技术。 不要被技术驱动，而是被问题领域或业务驱动。

我相信下面的pdf会给你更大的图景。Eric Evans的领域驱动设计

注意:想一个你可以从事的项目，应用你了解的小事情，并看到最佳实践。它还将帮助您提高微服务架构设计方法的能力。

我不想重复别人的答案，所以，简而言之，我解释一些常见的误解

Practical resource: PATTERNS, PRINCIPLES, AND PRACTICES OF DOMAIN-DRIVEN DESIGN by Scott Millett It is a methodology for complicated business systems. It takes all the technical matters out when communicating with business experts It provides an extensive understanding of (simplified and distilled model of) business across the whole dev team. it keeps business model in sync with code model by using ubiquitous language (the language understood by the whole dev team, business experts, business analysts, ...), which is used for communication within the dev team or dev with other teams It has nothing to do with Project Management. Although it can be perfectly used in project management methods like Agile. You should avoid using it all across your project DDD stresses the need to focus the most effort on the core subdomain. The core subdomain is the area of your product that will be the difference between it being a success and it being a failure. It’s the product’s unique selling point, the reason it is being built rather than bought. Basically, it is because it takes too much time and effort. So, it is suggested to break down the whole domain into subdomain and just apply it in those with high business value. (ex not in generic subdomain like email, ...) It is not object oriented programming. It is mostly problem solving approach and (sometimes) you do not need to use OO patterns (such as Gang of Four) in your domain models. Simply because it can not be understood by Business Experts (they do not know much about Factory, Decorator, ...). There are even some patterns in DDD (such as The Transaction Script, Table Module) which are not 100% in line with OO concepts.