DDD快速hold住业务的利器.docxVIP

DDD-快速hold住业务的利器 3. 限界上下文 限界上下文是语义和语境上的边界，意味着边界内的每个软件模型的组件都有特定的含义并处理特定的事务，限界上下文中的这些组件有特定但上下文语境和语义理据。其中可以理解为限界上下文是一个问题空间以及这个问题的处理方案空间。 ·?问题空间: 给定项目的约束条件下进行高级战略分析与设计的各个步骤的地方。可以使用简约的图表来呈现争辩中高级的项目驱动因素，并记录关键目标与风险。 ·?处理方案空间: 真正实施处理方案的地方，这些处理方案在问题空间争辩中被识别为核心域，当限界上下文被当作组织的关键战略举措进行开发时，即被称为核心域。次要通过源代码和测试代码来实现限界上下文中的处理方案，也会在处理方案空间中编写代码，来支撑与其他限界上下文之间的集成。 ·?通用言语:? 团队在限界上下文中进展了一种言语用于表达其边界内的软件模型，这一言语在限界上下文中开发软件模型的每个成员使用。该言语就是软件模型团队沟通时使用的言语，而软件模型的源代码就是这种言语的书面表达方式，猛烈建议定义领域术语，比如某个英文单词就特定代表某个模型并写上该单词的备注解释，让不同地域、不同团队成员都可以精确?????理解公用言语的含义，该言语可用在数据库、系统设计、设计文档等等方面。 核心域的识别是一个持续的精炼过程，把一堆混在在一起的组件分别，以某种方式提炼出最重要的内容，这种方式也将核心域更具价值，可以让产品研发的资源更聚焦到最小化可行产品上，不断猎取用户反馈，并在这最小化可行产品上持续快速迭代，从而获得一个稳定的核心产品。一个团队应当在一个限界上下文中工作，每个限界上下文应当有一个独立的源代码仓库，一个团队可能工作在多个限界上下文中，但是多个团队不应当在同一个限界上下文中共事，应当接受和分别通用言语同样的方式，把不同的限界上下文的源代码与数据库模式隔离开，并且，将同一个限界上下文中的验收测试、单元测试和次要源代码存放在一起。 4.架构 在限界上下文中不只是一个领域模型，里面还包括了合理的架构用来组织领域模型，输出相关的领域力量。在限界上下文的很常见: 输入适配器，例如用户界面把握器、REST终端节点和消息监听器；编排用例和管理事务的应用服务；输出适配器，如长久化管理和消息发送器。 目前经常可以看到的几种架构风格: · 大事驱动架构: 是一种以大事为媒介，实现调用接口者和接口实现者之间的解耦，大事驱动则是调用者和被调用者相互不晓得对方，两者只和两头消息队列耦合。 ·?命令和查询职责分别(CQRS): 将读取和写入操作分成不同的模型，使用命令更新数据，并使用查询来读取数据，从不修改数据。命令应基于任务，而不以数据为中心。命令可以放置在队列上进行异步处理，而不是同步处理。 ·?响应式架构和Actor模型:? 是大事驱动的一种实现方式，特殊擅特长理多个客户端并发的向服务端恳求服务的场景。如Reactor模式会解耦并发恳求的服务并分发给对应的大事处理器来处理。目前，很多流行的开源框架都用到了reactor模式，如: netty、nio等，还有一种如Akka的actor模型。 ·?面对服务的的架构: 面对服务的体系结构，是一个组件模型，它将应用程序的不同功能单元通过这些服务之间定义良好的接口和契约联系起来。接口是接受中立的方式进行定义的，它应当独立于实现服务的硬件平台、操作系统和编程言语。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互，目前比较常见的是RPC架构，包括了服务注册中心，服务供应者、服务消费者三大组件。 ·?具象形态传输(REST):? 描述了一个架构样式的互联系统。REST约束条件作为一个全体应用时，将生成一个简约、可扩展、有效、平安、牢靠的架构。由于它简便、轻量级以及通过HTTP直接传输数据的特性。用于web服务和动态Web应用程序的多层架构可以实现可重用性、简约性、可扩展性和组件可响应性的清楚分别。 5.子域 ? ? ? ?? DDD项目中总会遇到很多限界上下文，这些限界上下文肯定会有一个成为核心域，而其他的限界上下文之中会存在很多不同的子域名。子域是整个业务领域的一部分，子域代表的实施一个单一的、有规律的模型，大多数的业务领域过于浩大和简单，难以作为全体来分析，因而我们只关怀那些必需在单个项目中涉及的子域，子域可以用来有规律地拆分整个业务领域，通过DDD来创建子域，它将会被实现成一个清楚的限界上下文。 项目中有三品种型的子域: ·?核心域:? 它是组织内一个独一的、定义明确的领域模型，要对他进行较大的战略投资，并在一个明确的限界上下文中投入大量的资源去构建通用言语，它是组织中最重要的项目，是业务的核心竞争力所在。 ·?支撑子域: 这类场景下提倡“定制开发”，能最大限度支撑核心域的进展为第一要义，