当领域驱动设计（DDD）遇到亚马逊创新公式（上）
这是在火币和GitChat主办的领域驱动设计线下活动的分享，应大家的反馈，重新激活我的公众号，跟大家一起分享和成长，下面是我的近期的一些思考和总结：
当我们在讨论领域驱动设计，我们在讨论什么？GitChat的谢老师开场说，DDD出现了十几年了，都快推不下去了，突然刮来一阵微服务的热浪，随之而来就是这两年国内的DDD社区的火热；但作为整天泡在客户一线业务的架构师，看到的情况却是，大部分用户反馈使用领域驱动在开发团队，非常的别扭，真正带团队能实现微服务架构，支撑业务敏捷发展的企业非常少；所以，开始正题之前，我们需要弄清楚，DDD为何出现？为何随着微服务的发展而真正流行？
软件研发交付难题 - 如何与业务一起比翼双飞？
软件开发是一项复杂的团队运动，随着技术的发展，解决问题的复杂度不断增大，代码量也不断增加；软件技术发展的使命之一就是控制复杂度，这些复杂度，包括业务复杂度（需求，规模），技术复杂度（代码含义模糊，非功能需求-安全、性能、高并发和高可用等等），还有项目管理复杂度（团队，文化，制度，工具等等）。
举例来说，亚马逊电商从1995年创立之初只有书这样一个单品，到现在的综合在线商城，站点上线第一行代码开始，一直膨胀成一个非常大的单体电商应用，后台数据库随着功能和数据量膨胀，表之间关系越来越复杂，同时商品品类和全球扩张，后台商品入库和上架等功能，创造了一堆的脚本和定时任务。从技术来看，这样的单体应用，除了后台技术人员比较辛苦外，似乎也没什么不妥；但巨大的单体应用，阻碍了新的功能需求的快速上线和电商站点的可用性问题，业务变化到应用的变更交付周期拉长人天耗费巨大，系统运维成本不可想象。
软件研发发展历史上，有很多理论框架和设计模式指导大家如何管理大型应用需求开发交付，提升软件质量，其中大家熟知的面向对象的设计模式，TOGAF企业架构，敏捷软件开发原则模式和实践，以及埃里克·埃文斯 的领域驱动设计都是这方面的优秀成果。
由于关系数据库长期统治对应用架构的影响，开发人员早已习惯重复开发CRUD的数据库管理系统，以数据库数据模型展开整个系统设计和落地，业务需求方和技术人员的沟通长期存在巨大鸿沟；以数据库为核心的架构，缺陷在于丢失了更重要的业务原语，而简化成技术层的CRUD操作，这样业务到技术实现就经历好几层的翻译，准确性可想而知；另外一个技术缺陷在于，很多逻辑紧耦合在数据关系上，牵一发而动全身。
企业复杂的内部应用集成和重构催生出一批SOA架构的理论和产品，而大规模互联网分布式应用的成功，奠定了分布式微服务体系架构在敏捷业务创新领域的广泛应用，而其中亚马逊AWS 的诞生更是大规模微服务系统一个有力的样板工程。Eric 在领域驱动设计这本书里面，强调业务领域和技术利用统一语音渐进融合的架构设计战略建模及战术落地相关的思考和总结。DDD 的核心内容就是，理解和独立出领域模型为核心，驱动技术人员思考业务边界和领域之间的互动关系。从原来的数据库为中心的架构转型到服务解耦+组织解耦的业务驱动，有非常多的挑战！
领域驱动核心就是多了一个领域层，这个领域是业务相关原语，随着业务价值变化而变化，通常每个企业的核心业务域是千差万别的，所以，在技术实现的时候，反复要问我们团队，我们多少比例的代码是针对业务本身，而业务本身对业务消费者有多大的价值？作为业务的技术实现方，一定要有手段通过量化方法，衡量你的业务价值，从而能精细化迭代升级。
领域驱动设计的设想非常美好，但通常研发团队很难推广，为什么？以前是由于基础技术不成熟，而云计算的出现，降低了技术门槛，各领域的小公司纷纷颠覆式创新并迅速发展壮大；以互联网思维，产品思维驱动的互联网公司高速发展路径被人们广泛认知；纯粹回到微服务技术落地角度，基于广泛的云服务，我们可以快速原型和测试上线，比如Eric提到的事件驱动架构，CQRS（命令查询分离架构）等，利用成熟的云平台，用户不需要重复构建轮子，更直接实现业务逻辑。
而到今天这个阶段，阻碍大家应用领域驱动设计的主要是组织和机制，如康威定律所揭示，设计系统的组织，其产生的设计和架构等价于组织间的沟通结构。要让业务和技术一起比翼双飞，除了团队对DDD认知之外，还需要土壤和生态；至于什么样的土壤和生态请关注后续第二篇。
文中提到的资源链接：
http://ddd-china.com/ 领域驱动中国
https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws AWS上微服务实现白皮书
近期原创：