数字化转型，架构先行；企业出海，架构先行；软件开发，架构先行。
软件架构(software architecture)是一系列相关的抽象模式,用于指导大型软件系统各个方面的设计。
随着技术的不断发展,架构也开始被越来越多地开发和使用。微服务架构着实为企业带来了非常大的影响,利用微服务架构进行软件开发已经成为当前非常流行的一种趋势。对于企业的数字化建设而言,微服务架构不但让平台变得更加规范化,同时也为大数据和云发展奠定了坚实的基础。
领域驱动设计（DDD）是实现微服务架构很好的理论基础。
在日常工作中使用领域驱动设计的工作很多。然而DDD经常被误解！掌握DDD是一件复杂的事情，需要掌握大量的知识和实践。
领域驱动设计峰会DDD China2019 架构进化论，和业界一起分享领域驱动设计（DDD）理论的最新发展动态和实践经验总结，一起探索领域驱动设计（DDD），及其“协作设计”的思想是如何在更大范围帮助业务实现快速响应，优化组织合作的。
今天我们一起来聊一下DDD（领域驱动设计）。
我们说任何技术演进不是一蹴而就的。我们一起回顾一下无DDD时代，我们是怎么做的？我们这么做遇到了什么问题？（互动）
程序员思维：
看需求（业务理解不清，不能达成共识），写代码（技术参差不齐，不一样的代码习惯），提测（延期、BUG频出【早上写BUG，下午改BUG】，上线（延期、运维困难。。。
架构师思维：
基于数据建模（业务覆盖率低），缺乏顶层设计（模型复杂），基于现有业务（落地困难），完全依赖经验（经验不足）。
运维思维：
微服务增多，导致依赖不清晰，高耦合（环形依赖、网状结构）-》高扩展性
微服务架构之后链路变长，无法追踪-》高可用保障
性能下降（响应慢、吞吐低）-》高并发、高性能保障
运维困难（无法快速定位问题，定位了问题无法快速修复）-》高可用保障
DDD为解决软件复杂性而生。
为什么DDD能够解决软件复杂性？（基于现有认知，互动回答）
1、通过统一语言，来达成共识，共识远比方案更重要。
2、通过DDD方法论，指导开发。
3、基于DDD战略设计，从顶层业务出发，使得尽量覆盖全业务场景；基于DDD战术设计指导业务落地；避免完全基于个人经验进行架构设计。
4、DDD不仅仅解决了软件复杂性，同时为我们未来的三高系统奠定了基石。
可给DDD下一个定义（总结如下）：
DDD是软件工程学发展至今，未来解决软件复杂性而形成的一套方法论，通过统一语言，促使业务参与方达成共识，并指导开发最终落地。它是一种从顶层业务出发，通过事件风暴、决策命令、识别领域等等一系列操作，帮助我们进行战略设计。并通过聚合、聚合根、实体、值对象、工厂、防腐层等等一些战术手段帮助我们进行战术设计。最终实现业务系统的三高设计。
“DDD不是银弹，它不能解决所有问题。”
抽象一下目前的软件现状：
1、混乱不堪的代码 2、拍脑袋的模型 3、庞大的系统
这个和我们上面针对不同角色思维分析是一致的。回到我们的主题，“为什么DDD能够解决软件复杂性？”
整洁代码架构
- 设计原则：依赖倒置原则，对比MVC分层原则
- 聚焦核心域：以领域为核心，对比ER数据模型设计
- 架构模式：六边形架构，对比三层架构
如何微服务落地？
- 敏捷迭代，放弃建模
- 框架易学，思想难懂