DDD领域驱动设计

我收到了许多高级Java开发人员的询问，他们渴望成为软件架构师或解决方案架构师，他们能做什么才能成为软件架构师？哪些书籍，资源或认证可以提供帮助？还有一般性的询问，例如您需要多少经验才能成为软件架构师等。过去，我一直向他们建议一些书籍以供阅读，以扩展他们的知识库，并从体系结构和设计的角度来看

如果您这些年来一直在企业软件体系结构的任何地方工作，您很有可能会遇到诸如“什么是微服务的正确粒度？”之类的问题。或“微服务和有界上下文是否相同？”在接下来的几段中，我将尽力澄清。 定义我想澄清的第一

DDD（域驱动设计）是微服务体系结构的核心和最重要的基础。不了解DDD就无法掌握微服务架构真正的美丽之处。微服务架构顾名思义是一种将后端应用构建为一组小型服务的方法。每个服务都在自己的进程中运行，并使用HTTP / HTTPS，WebSocket或AMQP等协议与其他进程进行通信。每

我不会成为程序员的原因，因为我只是对数学问题没有兴趣。除了实用算法以外，我对算法没有任何兴趣。嗯 我的确对领域建模深有感触。我对领域建模深有深厚的感情，我与Eric Evans有类似的领域驱动型设计感觉。我喜欢与业务领域打交道。我喜欢找到正确的词。我喜欢将其分解，将主要模型分解，并将

在社会技术系统中调整有界上下文，以支持业务价值流。当您能够了解业务的价值流时，请在DDD战略层面上使用它们。例如，在一家在线销售实物商品的电子商务公司中，体现业务价值流的活动包括： （根据物理位置或从远程）获取要出售的物品 描述其物理细节（颜色，质量，图片和其

TOGAF数十年来的方向出错了：数据架构竟然是信息系统架构的一部分，其实信息系统架构应该是和数据架构没有依赖的，数据应该与技术无关。 众说纷纭：流程的二重性在哪里？光有数据是没有用的，只它在为业务目标而处理时它才能获得价值。（数据架构应该放

聚合是领域驱动设计DDD中最容易被误解的概念之一，只是一堆实体和值对象吗？还是更多？什么是聚合？当然，这是领域驱动设计的核心模式……但这只是对象的集合吗？马丁·福勒（Martin Fowler）解释说： 聚合是数据存储传输的基

EventStorming是一种基于研讨会的方法，可以快速找出软件程序领域中正在发生的事情。与其他方法相比，它非常轻巧，不需要计算机的特别支持。在宽阔的墙上的粘便笺表示。业务流程被“冲出”为一系列领域事件，这些事件被表示为橙色便签（维基百科定义）我与EventStorming的第一次

使用微服务意味着从松散耦合的服务创建应用程序。该应用程序由几个小服务组成，每个小服务代表一个单独的业务目标。在复杂

这两种建模方式都是围绕事件展开，但是有区别，事件风暴将会比普通的事件建模在思考层次上更高级，这需要从思维机制讨论：大脑是一个处理信息的机器，它学习速度很快，可以立即处理数据负载。那么，知识是如何构建的？在何处存储？人的记忆可以分为两类：语义记忆和情景记忆。 情

尽管微服务中的“微”一词表示服务的规模，但它并不是使用微服务的唯一标准。当团队转向基于微服务的架构时，他们旨在提高敏捷性以及自主且频繁地部署功能。很难确定这种架构风格的简单定义。我喜欢

将大型复杂系统模块化为更小和更易于管理的部分是一种最佳实践，这不仅是为了降低每个部分的认知负担，而且还可以降低团队的独立性和运营弹性。棘手的一点是如何划定边界，使整个系统稳定而可持续。带有边界的上下文是领域驱动设计的一种方法，业务领域的语言用作指导，还有另一种方法是从业务模型定义的功

一种流行的方法是出于技术考虑进行包装Package。但是这种方法有一些缺点。相反，我们可以按功能打包并创建自包含且独立的程序包，结果是一个易于理解且不易出错的代码库。 按技术打包类的缺点： 对属于某个要素的所有类的概述不佳。 通用代码，重用代码和复杂代

问题：当我4岁时，我妹妹2岁，现在我44，我妹妹多大？程序员：44 - (4 - 2) = 42测试员：很困难有一个答案。她可能是42岁，但她也可能是41岁或43岁，因为您没有说生日。而且，她可能已经死了。最后，您可能以为她是您的妹妹，但实际上你妈妈和另一个男人有外遇，其实比

EventStorming是超越孤岛边界进行协作的最明智的方法。EventStorming的力量来自于一个多元的，多学科的人群，他们在一起拥有很多智慧和知识。虽然最初是为研讨会设计的，以模拟领域驱动的设计集合，但现在它的应用范围更广。从获得整个领域的全局问题空间到深入了解整个软件交付流程并制

以下三点使您成功完成任何项目的90％的方法（不考虑可能的组织问题）： 跟随YAGNI和KISS YAGNI代表“您将不再需要”，并主张不要花时间在目前不需要的功能上 KISS致力于使其余功能保持简单 实施域驱动设计（DDD）。尤其是