引言
我想谈谈将DDD实践应用于现有Ruby on Rails项目的经验。 最初，我们编写了10年的巨著。 该项目的主要困难在于相当复杂的过程以及高度的连通性。 我们不仅设法将应用程序分解为单独的服务，而且还大大提高了代码的可读性，使所描述的过程透明。
系统中的问题解决变得可以预测，我们停止使用黑匣子，最后，系统本身开始提示我们提供解决方案。
为了促进感知和写作，将以一系列文章的形式介绍有关所使用方法的故事。 这种方法不是“灵丹妙药”，因此我想首先强调该解决方案可以适合的所有项目部分。 此外，我将更详细地讨论这种模式的DDD方法和微服务实现，我将在考虑其实现的情况下描述所应用模式的可能组合，最后，我将给出一个小型服务的具体实现示例。
词库
同义词库是用于描述特定主题领域的术语词汇表。
在本文的框架内，下面将介绍的所有定义都是正确的。 如果他们对主题的描述足够好，则可以将其应用于主题领域。
在此方法框架内解决的问题
下文描述的方法具有相当狭窄的专业性，并且首先旨在解决特定问题。 但是，这并不排除相关领域专家可能的兴趣。 因此，我们有任务：
您需要使用足够的资源来重写和维护一个使用Ruby on Rails编写的复杂业务逻辑的项目。
让我们更详细地编写此任务。
为什么需要重写项目？
我认为每个开发人员都可以回答这个问题。 很难回答，这样才能满足您的业务需求。
尽管我们将在这个术语中投资更广泛的概念-企业（由一群人从事的事情），职业（忙碌），但我们使用公认的“ 业务 ”定义。
商业是人的共同努力，通过旨在为广大个人谋取利益的行动来表达。
例如：
- 该公司为消费者生产产品或提供服务。
- 实验室正在开发一种新药。
- 学校从事培训。
- 城市档案馆为市民提供信息。
- 莱拉（Lera）在社交网络上以出色的形象取悦她的粉丝。
在大规模情况下，企业是通过满足客户需求来获利的想法而建立的。 为了增加利润，有必要使用大量高质量的解决方案来满足客户的实际需求 。 尽管这个想法并不陌生，但它被描述为敏捷清单的首要原则。 需求是我们社会的基础这一事实已被许多哲学家争论。 例如，柏拉图试图简化需求，创建需求分类。 是他列出了经济需求的主要形式：食物，衣服，住房。 “业务的挑战”是满足需求。 所采用的解决方案将提高企业的竞争力。
竞争力 -一项业务相对于另一项业务的优势。
敏捷宣言也向我们暗示，项目的灵活性通过其卓越的技术和设计质量得以增强。
在“典型的Web项目”示例中考虑价值的供应链
- t 0-我们有了一个主意。
- t 1我们实施了MVP 。 在这里，我们有点离题：
MVP最低可行产品-具有最低数量但足以满足第一个消费者的功能的产品。 主要任务是获得反馈，以形成用于进一步开发产品的假设。
这个词由史蒂夫·布兰克和埃里克·里斯推广。 MVP是测试您的业务构想并回答主要问题“起飞-不会起飞？”的有效工具。
- t 2-返回时间表。 这个想法很成功，我们收到了积极的反馈，并能够在指定的时间满足大量客户的需求。
- t 3-这次满意度降低了。 我们增加了工作人员。
- t 4-我们交付的价值甚至更少。
- t 5-如果我们没有开始重构，那么此时业务将不再具有竞争力。
为什么会这样呢？ 随着时间的流逝，我们的项目由于其高度的连通性而积累了高水平的熵。 假设我们有一个由营销，分析，物流，销售和管理部门组成的“典型公司”。 目前，该项目如下：
我想立即保留一个观点，即连通性并不总是导致熵的原因，但是如果实施具有大量复杂业务流程的系统，则会出现这种情况。
如果公司的业务流程格式不正确，代码中的熵总是会发生。 这两个年轻公司的特征（都处于起步阶段），也可能是大公司的特征，在大公司中，不可能一次将所有事物系统化。 这是一个自然的过程，我们不应阻挠他，而是接受并使用它。 让我们回到第一个图表并从另一侧看一下：
积分（线下的面积）将是所赚的钱。 至少直到熵t 4出现之前，真实应用程序（Real app）的收入将超过“理想”应用程序（Academinmin应用程序）。 听起来不错，这就是您需要做的。
但是将来该怎么办？ 重复重构到无限是不可能的。 在某个时间点，代码库的数量将达到无法立即“全部重写”的水平。 迟早有必要将项目分解为单独的组件：
DDD的一种实现方法是：
域驱动设计（DDD）是通过将实现与持续开发过程中的主要业务模型紧密地联系在一起，从而满足复杂需求的软件开发方法。
DDD是一系列实践和定义，将在下一篇文章中更详细地描述。 这种方法的主要模式是“ 有界上下文” ，其实质是每个主题领域由不应该与外界通信的几组模型以及与其他有限上下文结合在外界中使用的模型组成。 每个有限的上下文都有一个明确定义的界面，在该界面中可以决定将哪些模型与其他上下文结合使用。
可以通过名称空间（名称空间）和微服务来实现此模式。 我们将根据上下文连接级别使用这两种实现。 最终导致创建分解的分段应用程序。
上面的图表不太可能反映真实情况，但是可以让您比较它们之间的不同方法。
项目支援
作为项目支持的一部分，需要提供许多东西。
- 价值交付 ：Scrum，敏捷，客户服务，持续交付。
- 减少熵 ：DDD，微服务是分隔上下文和文档的一种方法。
- 代码质量 ：域级设计，TDD，BDD。
- 产品质量 ：手动和自动测试，错误跟踪，日志记录。
- 产品可用性 ：复制系统。
- 产品速度 ：水平缩放。
- 保留开发团队 ：激励机制，开放，诚实。
如您所见，维护复杂的系统需要大量资源。 首先，高素质的人才。 在使用该技术之前，请考虑一下您是否有机会在适当的级别上提供其支持。
应当记住，进入复杂系统的门槛很高，因此对人员进行培训很重要。 同样，如果我们想没有失败地工作，我们就不应有“不可替代”的专家，因此有必要确保所有角色的完全互换性。 如果您有一名“持续交付专家”从团队中撤出，则需要替换他。 如果无法提供替代产品，那么在没有提供足够支持的情况下，不值得将技术堆栈引入“生产”中。
这与同一级别的专家无关。 让您拥有领先的DevOps和特定的开发人员，这个主题对于他们来说很有趣（所谓的“多类”）。 对他来说，对于“第二把小提琴”，重要的是要了解在哪里以及如何找到解决问题的工具。 为此，应将与新专业相关的传入任务总量的至少四分之一分配给它。 这些任务将缓慢执行，成本将增加，但是将来这将防止由于人员短缺而中断价值提供的风险。
这样的事情在Scrum的需求中有所描述，我不想赘述。 我要引起您注意的唯一一件事是，需要准备的是支持项目所需的巨额成本。 如果您的企业还没有做好准备，并且您开始使用许多昂贵的工具，那么您将毁了企业。
简要地
- 如果需要实现MVP ，请从Ruby On Rails开始。
- 如果MVP取得成功并且这个想法成立了，请进行第一次重构，使用服务，装饰器“减轻”模型的负担，将模型的验证和数据库层移到单独的问题中。 编写测试，文档。
- 如果您没有如此复杂的项目，并且可以通过优化模型来消除熵，请执行此操作。
- 如果您有一个合理的，可读的项目，并且需要提高它的生产率，同时可以按用户划分它，则可以使用缩放。 但是不要尝试按域将项目分解为服务。
- 如果您经营的是“复杂”企业，并且正在寻找一种可以上网的工具（为什么还没有完成？！），也可以考虑使用现成的“企业解决方案”，例如使用Java或.NET。 所描述的做法源自此类解决方案，并且它们具有丰富的现成工具集，可为您节省金钱。
- 如果您的项目是在ruby上，那么您有一批ruby程序员，该项目包含复杂的业务逻辑，正在为加载做准备或已经加载，并且熵已经增长到非常难以重写的程度，那么您应该考虑使用DDD和Microservices方法。
下次，我想更详细地考虑DDD方法及其微服务实现的本质。
灵感来源：