一、序
2015年底初识DDD(领域驱动设计)，阅读和学习《领域驱动设计》By Eric和《实现领域驱动设计》By Vaughn，并且也在项目中进行了实践。随着时间的流逝， DDD对于自己也不再是高频词。最近由于各种原因，再次复习和采用DDD的方式思考和开发项目。这里把对DDD的最新理解分享个大家。DDD是一种思维方式，用以应对软件的核心复杂性。
本文把最近几个月对DDD的实践和最新理解分享给大家。
二、写在前头
如果：
1）你或你所在的团队要实现按时间倒排的需求？--需求的交付时间点已经设定
2）待落地的需求评估研发成本很高？--大于100人/天
3）是否需求的实现没有足够的资源？--缺少领域专家、架构、业务分析、开发和测试人员
4）是否需求很简单，但还存在很多不明确的描述？--离真正的用户距离很远或用户自己也不是很清楚想要什么
5）是否当前的研发人员的更擅长战术设计或惯用法？---应用过简单架构或熟悉特定的框架
6）你是一位热爱学习新的技能，不断进行自我提升的人？--自我驱动
那么：
在本文中你或许能够遇到引起共鸣的问题解决之道， 请享受接下来的时光：
1）战术设计：分层架构、六边形架构、依赖倒置等知识
2）惯用法：Rest、消息驱动、数据库技能
3）战略设计：子域划分、限界上下文的设计和映射
三、背景说明
为了配合文本的阐述，这里是假想的需求
1.原始需求：
提供数据库表视图，供第三方系统访问。
2.需求分析：
a)数据库表视图的描述？--部分信息
b)用户如何使用？--无明确说明
3.存在的问题
1）遗留系统上的需求，业务知识传递存在缺失
2）需求过于简单，缺少具体的约束
3）产品异地部署，需求沟通成本高，难以获取更多信息
4）遗留系统增量实现该需求，当前的架构支撑该需求存在风险
