让我们不要首先讨论DDD的定义，首先整理DDD Fire的背景。根据我了解的例程，这始终是为什么它首先是为什么解决的问题，什么是什么问题以及如何最终使用它。
我们都知道，随着多年来设备和技术的开发，软件体系结构发生了很大变化。从最初的立场（BS/CS）体系结构到后来的集中体系结构，再到当今的微服务体系结构，可以说，基本上是现在，这是既然是在微服务盛行的时代，DDD是由Eric Evans作为Eric Evans提出的早在2004年，但直到马丁·福勒（Martin Fowler）的“微服务”吸引了每个人的注意力，也就是说，微服务是普遍的（应该指出的是，微服务的最早提议不是马丁·福勒（Martin Fowler），而是弗雷德·乔治（Fred George）），DDD再次回到了人们的视野。为什么？
让我们看一下三种技术体系结构的发展和主要区别：
第一阶段是一个单位架构，其特征是数据库周围的整个开发的设计和开发。
第二阶段是三层集中式体系结构。它采用客观设计方法。业务逻辑被分为业务层，逻辑层和数据访问层。poor，此外，摩尔的定律失败，单个机器性能受到限制。
第三阶段是微服务体系结构。在集中式体系结构中，系统分析，设计和开发通常是独立的，负责每个阶段的人可能会有所不同。开发经验的过程非常长，最终很容易以不同的方式开发设计和设计。微服务主要是在第二阶段解决这些疼痛点，实现应用之间的脱钩，并解决了单个应用程序可伸缩性的问题。
进入微服务后，已经解决了集中式体系结构的单体应用的许多问题，但是已经出现了新的问题。微服务应该多大？如何设计微服务？如何拆分微服务？微服务边界在哪里？
长期以来，人们没有解决这个问题，甚至马丁·福勒（Martin Fowler）也没有告诉我们在提高微服务体系结构时如何分割微服务。
即使很长一段时间，人们也误解了微观服务的分裂。有人认为：“ Micro -Service很简单，也就是说，将先前的单个应用程序分为多个部署软件包，或单个应用程序构造的原始单个应用程序体系结构，即即使是支持微服务的一组技术体系结构，是微服务。“有些人认为应该拆分微服务越小，越好。
鉴于上述情况，由于早期分裂过度的分裂，许多项目都过度过度，导致难以操作和维护，甚至在后期的上网。
可以得出结论，拆卸微服务的基本原因是要知道业务或微服务的边界在哪里。换句话说，确定了业务边界和应用程序界限，并解决了这一难题。
DDD是解决确定业务边界的问题。可以看出，DDD不是技术体系结构，而是将业务范围划分的方法。DDD的兴起是由于许多工程师在执行微服务设计时熟悉现场驱动的建模（DDD），并找到微服务设计并查找并查找并找到与DDD梳理的业务可以很好地计划服务边界，并且可以实现“内部高级服务和外部”高级服务高服务高级服务“高服务高级服务”高服务内部聚会，低耦合”。因此，越来越多的人使用DDD作为商业部门的指导意识形态。
那么，什么是DDD？
通过上述研究，您可以知道DDD是拆卸业务，分裂业务和确定业务界限的一种方法。这是一种高度复杂的现场设计思想。实施的复杂性主要是解决该软件难以理解且难以发展的问题。DDD不是建筑，而是建筑方法论。技术架构的演变的良好实现。DDD包括两个部分，战略设计零件和战术设计零件
战略设计主要是从业务角度开始，建立业务模型，划分该领域的边界，并建立有限语言语言的边界背景。有限边界的极限上下文可以用作微服务的参考边界。
战术设计从技术角度开始，着重于现场模型的技术实施以及完整的软件开发和着陆，包括：设计和实施代码逻辑，例如聚合，实体，价值对象，现场服务，应用程序服务和资源库。
DDD战略设计将建立现场模型。这四个词会让人们感到非常深刻。实际上，这是一只纸虎。通常，它是模拟字段的模型。该模型更加抽象，但是人们可以进行交流。例如：公园里有一棵桃树。如果我们想研究桃树，我们该如何学习？
陶奇好吃吗？价格昂贵？品种吗？如何成长？它在哪里？制作桃剑？桃叶的价值？
您会发现，以这种方式研究每个问题是很有意义的，但是这很令人困惑。然后回想起初中生物学书中的这项研究吗？
首先，根据您的理解，将植物分为多个器官，例如桃子，桃子叶，桃花花等，然后根据功能将每个器官细分为组织。。
DDD也是如此。当我们面对桃树的复杂业务时，首先根据固有的理解将其分为多器官（字段），然后根据某些维度（以下是函数）分为一定程度（这里是功能）。聚集），每个组织由许多细胞（实体）组成，这是一种策略。有什么好处？它可以确保我们讨论的边界，也就是说，讨论是一个领域和一个维度。对于桃树，桃子，桃花开花，桃子叶和树干在不同的田地。Border，当我们确定这些领域时，我们可以确保我们在同一领域中讨论事物。这个优势是我们可以规定某些概念或术语。
DDD战略设计将建立域模型。现场模型用于指导微服务的设计和拆分。DDD的第一步是头脑风暴。可以理解，可以一起讨论对业务的理解。主要目的是我们的业务领域的细分而没有遗漏，就像刚刚刚好的桃树一样。首先要做的就是尽可能多地分析，以确保可以注意到每个字段。实际上，经常使用案例分析和场景分析。随着用户的旅程的分析，这是一个不同的过程。头脑风暴阶段将生成许多字段，命令，事件和其他字段。从不同的维度来看，我们将从不同的方面形成聚合，限制当代上下文等。收敛过程。
具体而言，我们可以使用三个步骤来确定域模型和微服务边界。
步骤1：整理业务过程中的用户操作，事件和外部依赖项，并梳理字段（例如字段）字段。
步骤2：基于字段之间的实体之间的业务相关性，与业务密切相关的实体合并以形成聚合，并同时确定聚合中的聚合，值对象和实体。在此图中。，聚合之间的边界是边界的第一层，它们以相同的微服务运行。该边界是一个逻辑边界，因此由虚线表示。
步骤3：根据业务和语义边界等因素，在有限的上下文中指定了一个或多个聚集体以形成域模型。在这张图片中，有限边界上下文之间的边界是边界的第二层。边界的这一层可能是未来微服务的边界。不同边界中不同边界中的场逻辑在不同的微服务示例中分离出来。分离，因此它由物理边界和边界之间的边界表示。
除了域，聚合和上述实体外，还有诸如聚合，值对象等之类的词。此外，还有统一的建模语言，子域，核心域，通用域，支持域，等等。之后，为了方便某个领域的讨论，通常会形成一些概念。这些概念将有一些名词。这就是上述名词的出现方式。这称为统一的建模语言。随后的文章将解释这些单词的含义，主要讨论DDD解决的问题。
为了整理DDD和微服务之间的关系，DDD是一种体系结构设计方法。微服务是一种建筑风格。从本质上讲，两者都是追求高反应，也是从商业角度的角度来看。核心要素是根据业务发展强调领域的发展，合理地分配了该领域的边界，不断调整现有结构，并优化了现有的代码以保持体系结构和代码的活力，这就是我们经常所说的Evolution structure.sendeddd主要关注：从业务领域的角度来划分该领域的边界，建立一种通用语言，以进行有效的交流，并通过业务抽象，建立域模型，并保持业务和代码的逻辑一致性.Micro -Service
注意： - 过程中的过程中 - 过程沟通，容错性和失败隔离，实现分散的数据管理和分散的服务治理，并注意微服务的独立开发，测试，构建，构建和部署。
本文主要讨论了DDD大火，解决行业问题，了解DDD的主要思想以及DDD的近似实施步骤的原因。
留下一个小问题：单个应用程序适合DDD？
作者：等不及口琴链接：http：//www.cnblogs.com/courage129/p/14839544.html