DDD领域驱动设计

好的技术设计决策严重依赖于上下文！定期为共同目标而合作的团队能够定期沟通并快速协商变更。这些团队表现出强大的一致性，并且可以利用这种强大的力量做出技术和设计决策；而独立工作且协作频率较低的团队和部门之间存在越来越弱的力量。<

这是来自martinfowler.com的Andrew Harmel-Law文章，大意如下，详情点击标题：架构设计不必是独白；不是从少数人的思想

Tomasz Jaskuła 是巴黎软件咨询公司 Luteceo 的首席技术官和联合创始人。Tomasz 拥有 20 多年作为开发人员和软件架构师的专业经验，曾就职于电子商务、工业、保险和金融领域的多家公司。他主要专注于创建能够提供真正业务价值、与战略业务计划保持一致并提供具有明显竞争优势的

是业务决定技术？还是技术决定业务？是人决定IT，还是IT决定人？这是康威定律与敏捷的区别：一位叫Melvin Conway学者进行了社

这是国家医保信息业务编码标准，按照“统一分类、统一编码、统一维护、统一发布、统一管理”的总体要求，将医疗保障编码标准统一为新时期医保信息交换的通用语言。搭建统一的动态维护平台，实行“纵向全贯通、横向全覆盖”，形成自上而下的统一标准规范的医保标准规范的编码体系，提升医保业务运行质量和决策管理水

人们经常会就如何探索模型寻求更具体的指导，尤其是在敏捷或精益环境中。这是埃里克·埃文斯 (Eric Evans) 试图以书面形式记录多年来以各种形式和设置与客户一起使用的流程。这不是一个开发流程。它应该适合大多数迭代设计的流程。

单一职责原则SRP，这是整个软件世界中最重要的单一规则。它几乎可以在我们系统的所有级别上看到：从单个类到整个应用程序（无论使用的规模和架构如何）设计。 什么是单一职责原则可能你们中的大多数人将 SRP 解释与一个声明联系起来——类应该

2010 年代是软件工程史上的一个转折点。在本世纪初，Eric Ries 通过url=https://www.amazon.com/Lean-Startup-Entrepreneurs-Continuous-Innovation/dp/0307887898]Th

Eric Evans在 2000 年代初撰写领域驱动

我工作的一个困难方面是充分了解客户在业务需求方面的目的和前景，以提供有用的建议并提出我可以如何提供帮助。我每个月都会与多家新公司讨论合作的可能性，所以这是我需要努力的一项重要技能。我正在从多个角度看待这一挑战，其中之一是找出我需要的关键信息。如果我能更早地捕捉关键信息，让我对业务架构

商业软件的最大问题之一是技术架构比领域模型获得的提升会更多。大多数领域模型都是普通的，并且可以由学校学生以比通常花费很少的成本来实现；然而，通常支持模型的软件架构，通常是过度设计的。一个常见的吹嘘是这样的：“该架构每秒可以处理 10,000,000 多条消息！” 但架构师无法证明这一

从 Spring Data JPA 1.11（Ingalls 版本）开始，您可以在保存实体对象时自动发布域事件。您只需要向实体类添加一个方法，该方法返回要发布的事件对象的 集合 ，并使用@DomainEvents注释该方法 。Spring Data JPA 调用该方法并在您执行 实体存储库的

许多软件架构试图将域逻辑与应用程序的其他部分分开。为了遵循这种做法，我们总是需要知道什么是领域逻辑，什么不是。不幸的是，这并不总是那么容易分开。如果我们做出错误的决定，领域逻辑很容易泄漏到其他组件和层中。我们将通过查看使用六边形应用程序架构的示例来解决这个问题。 假设

由于多种原因，企业中数据状态混乱，四个方面很突出：跨组织边界的零散所有权和问责制：信息孤岛、筒仓。数据库管理和数据工程等特定功能的集中化，但在整个企业游戏中没有一块完整的皮肤可用技能不平衡——软件开发团队很少将数据视为他们服务的一部分，数据

事件风暴将正式包含在下一版本敏捷框架 SAFe 中

API 设计的核心是有效的沟通，不仅是开发人员之间的沟通，还包括将产品思维、业务和技术融为一体的沟通。James Higginbotham 是《Web API 设计原理》的作者和执行 API 顾问。James 还推荐 API Design-First 方法——一种快速且轻量级的基于结