Vaughn Vernon举办了一场演讲，阐述了他所遇到的各种软件开发方面的严重问题，但也为这些问题提出了应对的方案。在他看来，大量的项目与开发团队都深陷设计糟糕的系统中难以摆脱，无数开发者在不停地为系统打补丁，只为系统能够继续运行下去。这使软件开发文化在很大程度上遭受了严重的破坏。
以Vernon的经验来看，有一种问题是最突出的，即IT部门被视为一个成本中心，业务部门将软件开发视为一种负面的因素，它在逐渐地榨干组织的资源，是一种金钱上的浪费。这样的业务部门不可能将软件视为一种改变游戏规则的因素，而是视为一种他们不得不忍受的东西。
在Vernon看来，让业务人员花费大量时间在协作工具中编写规格说明是一种毫无意义的浪费。大多数开发者都不会在意这些规格说明，因为其中缺少他们所需要的信息，反而只会造成低效的协作。正确的做法是让业务人员与开发者进行对话交流，从而在更短的时间之内推出一份能够满足业务需求的扎实的设计。
Vernon提到了一种被他称为任务板洗牌的做法：将某个便签从待办事项栏目里挪动至开发中栏目中就被视为软件设计的完成。这会导致每次挪动便签就带来一种随机的设计方案，造成系统缺乏所必需的、经过沉思熟虑的设计。有太多的人认为无设计是一种对代码或开发者时间上的节约，但Vernon认为这种节约是一种错误的做法，只会造成糟糕的设计。
Vernon坚定地相信，为了克服他所描述的这些问题，我们必须提高团队中的开发者成熟度。业务部门对于软件开发部门的看法只是某些对于业务有兴趣的人员，为了改变这种看法，我们需要通过创建解决方案，进一步促进业务发展的方式帮助业务部门实现卓越。而实现这一点的一种方案就是开始与业务部门进行合作。围绕着工作内容的上下文与模型建立团队，并设立统一语言。
事件风暴是一种领域建模的辅助工具，Vernon将其描述为发现边界上下文的一种极度实用与重要的工具。经过几个小时的讨论，或许就能够建立一种统一语言，并且理解领域中的边界上下文。在事件风暴会议中所产生的结果也可用于某种基于指标的估算过程的估算单元，其结果将接近于真实的数字。
微服务是时下的热门话题，Vernon认为它与领域驱动设计中的边界上下文有着相似之处。但在Vernon看来，以单一组件的粒度部署微服务似乎太细了，他认为以边界上下文的规模创建微服务是一种更为有效的途径。
Vernon随后提到了Actor模型，他确信这是一种非常重要的工具，开发人员 —— 甚至是多数开发人员都应当开始使用这种工具。随着服务器的内核与内存的不断升级，Actor模型也表现为一种能够有效地利用这些新资源的方式。Vernon提出了一项建议，开发者可使用Actor模型，围绕着单一的边界上下文构建微服务。他认为Actor模型往往能够极大地简化系统的设计，这种设计表现出优秀的简洁性。与之形成鲜明对比的是，当今的企业软件往往会使用复杂的技术栈，其中包含大量不同的机制，哪怕是高级开发者也需要几个月的时间才能完全掌握。
Vernon在结语中表示，大量的团队都深陷设计糟糕的系统中难以摆脱，但随着开发者成熟度的提高以及DDD的普及，将对这一现状产生很大的改变。
本文转自d1net（转载）
