《领域驱动设计之PHP实现》全书翻译 - DDD入门

DDD 入门

1. 《领域驱动设计之PHP实现》全书翻译 - DDD入门
2. 《领域驱动设计之PHP实现》全书翻译 - 架构风格
3. 《领域驱动设计之PHP实现》全书翻译 - 值对象
4. 《领域驱动设计之PHP实现》全书翻译 - 实体
5. 《领域驱动设计之PHP实现》全书翻译 - 服务
6. 《领域驱动设计之PHP实现》全书翻译 - 领域事件
7. 《领域驱动设计之PHP实现》全书翻译 - 模块
8. 《领域驱动设计之PHP实现》全书翻译 - 聚合
9. 《领域驱动设计之PHP实现》全书翻译 - 工厂
10. 《领域驱动设计之PHP实现》全书翻译 - 仓储
11. 《领域驱动设计之PHP实现》全书翻译 - 应用服务
12. 《领域驱动设计之PHP实现》全书翻译 - 集成上下文
13. 《用PHP实现六边形架构》

若是你已经读过 Vaughn Vernon 和 Eric Evans 著做里的这些主题，你可能会很熟悉咱们讲的是什么，由于咱们大量借鉴了他们的定义和解释。领域驱动设计（DDD）是一种帮助咱们理解和构建软件模型设计的方法。它提供了战略和战术模型工具来帮助咱们设计高质量的软件从而达到咱们的业务目标。

本书的主要目标是向你展现领域驱动设计战略模式的 PHP 代码实例。若是你想了解更多战略模式和领域驱动设计的核心，你最好去读 Vaughn Vernon 的《领域驱动设计精简版》和 Eric Evans 的《领域驱动设计参考：定义和模式摘要》。

更重要的是，领域驱动设计不是关于技术的。相反的，它是关于围绕业务挖掘知识，用技术来提供商业价值的。只有当你有能力理解你公司的业务时，你才可能参与到软件模型的探索过程，从而获得一个通用语言（Ubiquitous Language）。

为何领域驱动设计重要

软件不只仅是代码。若是你好好思考过这一点，代码绝非咱们所追求的最终目标。代码只不过是解决业务问题的手段。领域驱动设计强调要确保业务和软件使用同一语言。因此为何非要用不一样的语言来说述呢？只要打破其中壁垒，就再也不须要翻译或者繁琐的同步过程，信息也不会丢失。每一个人均可觉得探索业务领域作出贡献，而不只仅是程序员。最终所产出的软件就是公共语言的真实体现。

领域驱动设计同时提供了战略和战术设计的框架 -- 战略设计精肯定位业务中最重要的领域，根据业务价值来进行开发；战术设计则经过久经考验构建块和模式来创建可工做的领域模型。

领域驱动设计的三个核心

领域驱动设计是交付软件的一种方法，它主要汇集三个核心要点：

1. 通用语言

为了创建业务领域的共同语言，领域专家和软件开发人员须要一块儿工做。这里没有咱们与他们之分，这里只有咱们。开发软件是一种商业投资而不只是花销。为构建通用语言而做出的努力将帮助团队全部成员对领域有更深的认识。

2. 战略设计

领域驱动设计指明业务方向背后的战略，而不只仅是技术层面。这有助于定义内部关系和早期预警反馈系统。在技术面，战略设计经过提供如何实现面向服务架构的动机来保护每一个业务服务。

3. 战术设计

领域驱动设计提供工具和构建块来持续交付软件。战术设计工具产出的软件，不只是正确，并且同时是易测试的和出错少的。

通用语言

通用语言，以及第十二章整合限界上下文，是领域驱动设计最具威力的一部分。

就上下文而言
如今设想一个限界上下文就是一个系统内的概念边界，边界内的通用语言是有其特殊含义的，而边界外的上下文概念可能有不一样的含义。

那么，如何寻找，发现和捕获这些很是特别的语言呢，下面将列出几个要点：

• 识别业务流程的关键点，输入和输出
• 建立一些词汇和定义
• 用一些文档来捕获重要的软件概念
• 与团队其余人分享和扩展以上知识（开发人员和领域专家）

自从领域驱动设计诞生以来，改进构建通用语言进程的新技术层出不穷。其中最重要的也是现今使用最广泛的，就是事件风暴。

事件风暴

Alberto Brandolini 在一个博客帖子上介绍了事件风暴及其好处，他解释得比咱们简洁多了。事件风暴，就是一种快速发现复杂业务领域的研讨会形式：

• 它很是强大：它让本身和许多参与者在数小时内提出一个完整业务流的综合模型，而之前每每须要数周。
• 它很是吸引人：它整个想法就是为了构建一个模型而把有疑问的人和知道答案的人聚在同一个屋子里。
• 它很是高效：它所获得的模型彻底切合领域驱动设计的实施方式（尤为适合一种事件源方法），并能够快速肯定上下文和聚合边界。
• 它很简单：它的表示符号很是简单，也没有复杂的 UML 以至参会者想从讨论核心中抽身离开。
• 它颇有乐趣：我老是能主持一个美妙的工做会议，你们老是很投入并能提出超出他们预期的东西。正确的问题浮现了，气氛也是融洽的。

若是你想对事件风暴了解更多，请查阅 Brandolini 的书 《Introducing EventStorming》。

关于领域驱动设计

领域驱动设计并非银弹，就像软件里的一切都依赖于上下文。做为一个经验法则，使用它可让你的领域模型简单化，毫不会增长复杂性。

若是你的应用仅仅是以数据为中心，用例也主要是在数据库行列上作 CRUD 操做，即增删改查，那么你并不须要领域驱动设计。你所须要的仅仅是在数据库之上作一个漂亮的前端。

若是你的应用少于 30 个用例，那最好使用像 Symfony 或者 Laravel 这样的框架来简单处理你的业务逻辑。

但是，若是你的应用超 30 个用例，你的系统可能走向一个可怕的大泥球。若是你知道你的系统肯定无疑会变得愈来愈复杂，那么你应该考虑用领域驱动设计来应对这些复杂度。

若是你并不理解你工做中那些领域，由于它们很陌生，以前也没有任何人给出解决方案，那么对你来讲应用领域驱动设计将变得很复杂。在这种状况下，你最须要与领域专家紧密工做来获得正确的模型。

棘手的部分

应用领域驱动设计并不容易。它须要时间和努力来投入到业务领域，术语，文献中，而不是代码堆里。你须要领域专家承诺参与到整个进程当中。这须要一个开放的，友好的持续交流，来将他们的行话（spoken lauguage）转化为咱们的软件模型。另外咱们要努力避免使用技术思惟，而应该首先认真思考对象的行为和通用语言。

战略总结

为了给出领域驱动设计战略这部分一个整体归纳，咱们将用 Jimmy Nilsson 的书《应用领域驱动设计与模式》中的一种方法，即考虑两个空间：问题空间和解空间。

在问题空间里，领域驱动设计用领域和子域来规划和规类公司想要解决的问题。在在线旅行社（OTA）这个例子当中，问题是关于处理像航班机票，酒店预订这样的事情。这样的领域就能够规划为不一样的子域，如价格，库存，用户管理等等。

在解空间里，领域驱动设计提供两种模式：限界上下文和上下文映射图。其目标是定义如何为全部已识别的子域提供一个实现，经过定义他们的交互和这些交互的细节。继续用 OTA 这个例子，每一个子域问题都将用一个限界上下文实现来解决。例如，一个由价格管理子域团队开发的自定义 web 应用，以及用户管理子域的一个现成解决方案。上下文映射图将展现每一个限界上下文是怎样与其它部分发生关联的。在上下文映射图内，咱们能够看到两个限界上下文间有什么关联形式（例如：客户-供应商，伙伴）。理想的方案是每一个子域由一个限界上下文实现，但实现不可能老是如此。就实现来讲，依照领域驱动设计你就最终以一个分布式架构结束。正如你已经知道的，分布式架构远比单体架构复杂，那么为何这个方法有意思，尤为是对大而复杂的公司来讲？这真的值得吗？是的，它值得！

分布式架构被证实能提升企业总体生产效率，由于它能为你的产品定义好边界，从而让专门的团队来开发。

若是你须要解决的领域问题不是很复杂，应用领域驱动设计的战略部分会增长没必要要的开销同时会拖慢你的研发速度。

若是你想了解更多关于领域驱动设计的战略部分，你应该去看看Vaughn Vernon的书《实现领域驱动设计》的前三章，或者Eric Evans的《领域驱动设计：软件核心复杂性应对之道》，两者对于这方面都有专门的讲解。

相关趋势：微服务与自包含系统

如今还有一些其余遵循领域驱动设计的相关运动正蓬勃发展，微服务和自包含系统就是很好的例子。James Lewis 和 Martin Fowler 在 Microservices Resource Guide 里是这样定义微服务：

微服务架构风格是把单个应用的开发分解为一个个小的服务的方法，每一个服务都有本身独立的进程和轻量的通讯机制，一般是用 HTTP 资源的 API。这些服务都是围绕其业务能力构建，可独立部署自动升级，去中心管理。服务能够用不一样的程序语言编写，使用不一样的数据存储技术。

若是你想了解更多关于微服务的内容，他们的指导就是一个良好的开端。微服务是怎样与领域驱动设计发生关系的？按照 Sam Newman 《微服务设计》 一书中的解释，微服务就是领域驱动设计的限界上下文的实现。

除了微服务，另一个相关的趋势就是自包含系统（SCS)，依据自包含系统官网的解释：

自包含系统是关注将功能分离至许多独立系统的一种架构，由这些独立系统相互协做来提供一个完整的逻辑系统。这能够避免单体系统不断成长致使最后变得不可维护的问题。纵观过去的几年里，咱们看到许多中型和大型项目受益于此。这个思路是把一个大型系统分解为一些更小的自包含系统，依照下列肯定的规则（官网上一样有阐明自包含系统 的七个特征）：

1. 每一个自包含系统是一个自治的web应用。对于自包含系统里的全部处理数据的逻辑和全部渲染 web 界面的代码都包含在其中。一个自包含系统能够彻底自主处理其全部的用例，不用依赖其它可用的系统。
2. 每一个自包含系统由一个团队管理。这并非必然意味着只有一个团队才能够改变代码，不过全部者团队能够最终决定什么能够放进代码库，例如合并，拉取请求。
3. 不一样自包含系统或者第三方系统间的通讯任何状况下都应该是异步的。尤为是其余自包含系统或扩展系统不该该同步访问自包含系统内的请求/回复。这一点能帮助解耦系统，减小失败结果，所以能支持自治性。其目的是关于时间上的解耦：一个自包含系统能够很好的工做即便其它自包含系统临时离线。即便通讯技术层次是同步的也能实现，例如复制数据或缓存请求。
4. 一个自包含系统有可选的服务 API。由于每一个自包含系统都有本身的 web UI 同用户交互，因此不须要一个 UI 服务。不过即使如此，为移动客户端或者其余自包含系统而存在的 API 仍然是有用的。
5. 每一个自包含系统必须包含数据与逻辑。要真正实现任何有意义的功能，二者都是必需的。一个自包含系统应该经过自身实现全部功能所以二者缺一不可。
6. 一个自包含系统经过自身的UI将功能交给最终用户使用。所以自包含系统不该该与其余自包含系统共享UI。自包含系统可能仍旧与其它系统有关联。不过，异步整合意味着即便在其余自包含系统不可用的状况下还应该能正常工做。为避免紧耦合，一个自包含系统不该该与其余自包含系统共享业务代码。也许能够经过建立一个自包含系统或者公共库，例如：数据驱动层或者认证客户端。

练习

与你的同事讨论例如分布式架构的利弊。考虑用不一样语言，部署过程，责任心等等。

小结

在这一章里你将学到：

• 领域驱动设计不是关于技术的；它的价值其实是经过聚焦你工做领域中的模型体现的。每一个人都参与到领域发现的过程，开发人员和领域专家用相同的语言来共同创建知识，即通用语言。
• 领域驱动设计提供战术和战略模型工具来设计高质量软件。战略设计关注业务方向，帮助明确内部关系，用明确的强边界严格地保护好每一个业务服务。战术则为迭代设计提供有用的构建块。
• 领域驱动设计只有在明确的上下文中才有意义。它并非软件中全部问题的银弹，因此是否用它应根据你手中工做的复杂度来决定。
• 领域驱动设计是一项长期投资；它须要长期努力。开发人员须要与领域专家紧密合做，同时要根据业务思考。最后，业务中的客户因素也是须要你考虑的。

实现领域驱动设计须要努力。若是它很简单，那每一个人均可以写出高质量代码了。准备好了，由于你立刻就要开始学习怎么写这些代码了，在读的过程当中，你将能够完美地描述清晰你公司现有的业务。享受这段旅程吧！