领域驱动设计精粹¶
评分: 7.6 132 人评价
时间: 2018-09
作者: 【美】Vaughn Vernon（沃恩・弗农）
原作名: Domain-Driven Design Distilled
译者: 覃宇 / 笪磊
覃宇，ThoughtWorks 高级咨询师，10 余年移动应用开发经验，Android 技术专家，曾为 AOSP 贡献过测试用例；目前专注于移动应用的架构设计、自动化测试以及持续交付。译有《Kotlin 实战》《Severless：无服务架构与 AWS Lambda》等书。
目录
架构风格和模式，如:
事件溯源
CQRS
REST 风格的架构、
事件驱动的架构
六边形架构，
关于设计是否必要或是否负担得起的问题根本都没有问到点上：设计是不可或缺的。除了优秀设计就是糟糕、设计，根本不存在“不做设计”一说一一摘自 Douglas Martin 的 Book Design: A Practical Introduction 一书
第 2 章 运用限界上下文与通用语言进行战略设计¶
限界上下文 Bound Context)
通用语言 Ubiquitous Lαnguage )
如果刚刚开始投入到软件建模中，限界上下文多少是有些概念化的。你可以将它理解为问题空间 Problem Space 的一部分
随着软件模型开始呈现出更深层次以及更清晰的含义时，眼界上下文将会被迅速转换到解决方案空间( Solution Space )中
请记住 模型是在限界上下文中实现的，你也将会为每个眼界上下文开出不同的软件
问题空间是在给定项目的约束件下进行高级战略分析与设计各个步骤的地方。你可以使用简单的图表来展示讨论中高级的项目驱动因素，并记录关键目标与风险。在实践中，上下文映射图可以在问题空间中工作得很好。同时还要注意，限界上下文不仅可以在需要时用于问题空间的讨论，也与你的解决方案空间密切相关
解决方案空间 就是真实施解决方案的地方，这些解决方案在问题空间讨论中被识别为核心域（ Core Domain )。当限界上下文被当作组织的关键战略举措进行开发时，即被称为核心域。你将主要通过源代码和测试代码来实现限界上下文中的解决方案，也会在解决方案空间中编写代码，来支撑与其他限界上下文之间的集成
备注
DDD 首要价值主张：哪些是核心域，而哪些不是