DDD领域驱动设计

领域驱动设计DDD有两个难题：给事物命名，以及在另一个有界上下文中再次命名它们

微服务是开发软件的最具可扩展性的方式。但是你需要一个好的设计，让开发团队自主工作和部署，而不会互相干扰，否则你将失去可扩展性的好处。领域驱动开发允许我们通过将更大的系统分解为独立的单元、了解每个单元的职责并确定它们之间的关系来规划微服务架构。在本文中，我们将学习领域驱动设计的基础知识

软件设计是一个不断发展的过程。每一个大系统都是从一个小系统开始的。当现有架构遇到问题但无法解决时，系统将开始演进。每一次进化都伴随着一些技术选择。应该解决哪些问题？它会付出怎样的代价？作为架构师或高级工程师，必须找到合理的演进方式，无论开发进度、技术堆栈、团队水平如何，都必须能够满足这些标准

上下文映射，最早是由Eric Evans在领域驱动设计中描述的，是一种轻量级的方法，用来描述系统和系统的一部分之间的关系。 它本身不是技术性的。它暴露了组织的政治和构建系统的团队。当你开始绘制时，连接两个系统的每条边都定义了一个上游和一个下

程序员职业生涯两次落泪时刻：1、大学毕业后

经营传统农场绝对是一场噩梦。你必须喂食动物，把它们赶出去，安排兽医的拜访，种植庄稼，驱赶害虫，并同时处理数百项其他任务。把所有东西都放在正确的地方一定是一份全职工作。鸡无意识地四处游荡，被狐狸抢购一空，羊跳篱笆，荆棘丛生侵入你的土地。分离农场的不同功能区域是其成功管理的关键。

微服务听起来很棒，它们是模块化的、可扩展的和容错的。很多公司都使用这种模型取得了巨大的成功，因此微服务可能自然会成为卓越的架构和启动新应用程序的最佳方式。然而，大多数在微服务方面取得成功的公司并不是从它们开始的。考虑一下 Airbnb 和 Twitter 的例子，它们在超越了单体应用

虽然事件确实无处不在，但受欢迎程度的增长似乎导致术语准确性的丧失。Apache Kafka 成为“事件总线”，所有异步消息都被声明为事件，使用事件流被声明为 Event Sourcing，像这样模糊不同的概念对架构讨论没有帮助。 术语Event S

学习领域驱动设计、软件架构、设计模式、最佳实践，该项目的主要重点是提供有关如何设计软件应用程序的建议。本自述文件中介绍了从不同来源收集的一些技术、工具、最佳实践、架构模式和指南。代码示例是使用

软件的核心是处理和解决可用的业务上下文和问题。今天的企业业务领域通常是庞大而复杂的，并且正在增长/变化——以及接受这种增强的软件。领域驱动设计 (DDD) 是一种软件开发方法，其中软件工件与核心业务概念和目标完全一致。领域驱动设计由

本文将介绍如何将域驱动设计和数据库组合在一起的另一个示例。接下来，我们将提供一个带有 MySQL 数据库的普通街头gashapon（扭蛋娃娃机）店的真实设计。 用户故事正如我们之前所做的那样，我们从描述用户

DRY是我遇到的第一个编程原则，可能也是我在成为开发者的第一年中唯一意识到的原则。它也可能是最简单的理解原则之一。如果你在你的代码中看到两件相同的东西，也许它们就应该是一件东西。这一点很难说得通。但是，我认为DRY就像其他的原则一样--它有它的位置，但最好是适度的。而我认为，由于它的普遍性和

DDDLib是一个领域驱动设计（Domain Driven Design，简称DDD）类库，它的目的是： 为基于DDD的开发范式提供基本的接口和抽象，实现一致性。 支持业务代码和技术代码分离。使领域层代码纯粹表达业务概念和业务规则，将具体技术隔离出去。 隔离业

异常已经被引入来处理函数层面的错误。其目的是为了避免返回错误代码和消除返回类型的模糊性。异常的力量来自于它们通过堆栈向下传播的能力。你没有义务直接处理异常。它允许你将你的正常代码流与错误处理分开。 当函数对参数的假设被打破或者函数不能履行其承诺时，

共同理解并非来自“我分享我的理解，而你采纳它”。它来自“我分享我的知识，你分享你的知识，我们一起构建新的理解。” 一起做某事，建立共同的理解，然后每个人都可以做出兼容的决策。将单个一个人的心智模型强加于团队的旧式风格在复杂性中是不起作用（而