当领域驱动设计（DDD）遇到亚马逊创新公式（中）
在上一篇中，我们探讨了软件研发的复杂性问题，以及为了应对这样的复杂性，领域驱动设计的出现带来的新思路和设计方法；但理论还需结合实际；可以说，微服务本身的理念和DDD不谋而合；那很多客户的困惑就在于如何拆分微服务，DDD给大家的答案是通过定位核心域、子域和支撑域，明确领域边界，从而抽象出自治高内聚松耦合的服务。
客户普遍反馈的最大挑战：如何拆分业务定义边界？
疑问一：是否可以直接购买现成的业务领域模型？
直接购买现成的方案，是客户非常熟悉的快速实现业务诉求的方式之一；就比如公司A准备上一个电商平台，目前的现状是，后台是历史遗留的竖井式商业支撑系统，但业务短期的诉求是如何服务好广大的终端客户，渠道大多数为移动APP和WeChat入口；期望，新系统能很好支撑新业务上线，业务的灵活变更等等；看起来直接购买可以省时省力，关键是后续的持续开发迭代如何做？所以，目前我看到这几种方式：
购买源码，自己团队消化，再进一步开发升级
全部外包，找一个类似业务领域经验的公司，复用他们的领域模型、框架和团队能力
基于SaaS化平台，标准模块+有限定制能力
最近看到还不错思路的某电商平台，好奇的同学可以进一步了解下：https://mp.weixin.qq.com/s/YRLBrGvAnYVeLT1mo62Dfg
再举一个例子就是涂鸦智能，他们提供了设备智能化的全套解决方案，可以快速帮助小家电、大家电等设备制造商，构建智能互联解决方案：https://aws.amazon.com/cn/solutions/case-studies/tuya/
疑问二：类似 AWS 这样的云服务有提供现成的行业化的解决方案吗？
AWS技术平台一直以来的口号就是Go Build！赋能开发人员创造创新的自由。今天我们探讨DDD更多会涉及业务领域如何对齐技术实现的命题；上一个章节所述，AWS的合作伙伴生态，有非常多的深耕各行业的解决方案，从我熟悉的领域来看，跟业务贴合非常紧密的云服务就是游戏行业解决方案，更多的内容可以参考官方资料(见文末资源链接）；
疑问三：社区还有什么参考的DDD落地方法？
回到领域驱动设计，为了对齐业务术语和技术名词，实现领域模型驱动的开发，DDD最核心的建议就是统一语言，至少在一个特定的界限上下文里面，消除业务领域“行话”的歧义，大家在同一个语境同一个理解上进行对话，比如我们讨论“下订单”，如果不是针对特定的上下文，每个人的理解都不一样，只有限定到比如咖啡店场景，大家才能无歧义沟通下去：
Eric 的十几年前的思考总结还缺乏具有实操意义的执行方法；所以，社区在实践中发明了事件风暴（Event Storming），在这样的Workshop中，参会者，利用不同颜色的便利贴和记号笔，统一语境：用户，命令，事件；不断挖掘特定业务场景的核心用户事件线索；并可以进一步进行战术建模，实现最小原型产品（MVP）；
如果大家想体验一下事件风暴Workshop给团队带来的体验，以及在AWS快速原型实现DDD项目，我特别推荐台湾同事Kim，他是无服务器领域的极客，又是台湾地区DDD社区联合创办人，他在Github上有个非常赞的事件风暴指南，欢迎大家跟他交流（Github地址见文末的资源链接）：
另外，实操层，DDD中国社区大会每年也会有很多的客户现身说法，大家想听DDD企业实战的可以关注。AWS 专业服务团队是可以帮助客户现场咨询和落地，大家可以联系对应的AWS同事。
文中提到的资源链接：
Kim 的 Run DDD on AWS 的 Github 地址
https://github.com/humank/EventStormingWorkShop/
https://www.eventstorming.com/ 事件风暴参考
Alberto Brandolini 事件风暴大神
https://aws.amazon.com/cn/gaming/resources/ AWS 游戏行业解决方案
近期原创：