DDD
1.软件项目成败的关键
介绍
据统计，软件系统建设项目的成功率均在30%以下，超过70%的项目由于项目延期、超出预算、功能缺失等失败甚至取消
软件项目的组成
- 构建人机接口（前端）：所有的系统都是为人服务的，人机接口的事似乎没有办法省掉。它一般承担收集输入和展示信息两项任务
- 基础设施：这项工作的本质是为系统在这个客观世界的存在创造物质条件，包括持久化、驱动硬件、网络通信等任务。选择越高级的语言和平台，这一部分要承担的任务就越少，反过来，开发者在这一部分可能就需要花大量工夫
- 业务逻辑：什么使你的系统与众不同？是因为它的业务逻辑不同、所在的领域不一样、传递的商业价值有差别，还是因为你选择的开发语言和数据库不同？答案是不言而喻的。系统中最复杂也是最模糊的地方就是领域逻辑，这是最需要投入工作量的地方
不会导致项目失败的部分
- 构建人机接口：这一部分的构建有一个明显的特点——用户的反馈是最快、最及时的，你根本不可能在错误的道路上走很久。他们会把清晰的需求画给你，甚至所有的交互细节和布局
- 基础设施：即构建基础设施会导致项目失败吗？这个可能性微乎其微。所有的开发框架、操作系统、中间件产品都经过成千上万项目的检验，问题不可能单独出现在你的项目上。退一步讲，开发团队在尝试某种新技术（比如新的PaaS）时，可能它还不够成熟，那么即使出了问题，也非常容易测试和定位。及早更换或者等待补丁，只要你不优柔寡断，它不可能给你带来问题
很有可能导致项目失败的部分
很多项目失败的原因是因为业务逻辑的原因，之所以有的项目成功，有的项目失败，是因为它们解决“如何构建领域逻辑”这个问题的重视程度和做法不同。而失败的项目无一例外都是在这个环节出了问题
业务逻辑不就是一些if…else的逻辑开关吗？这比搭建一个高可用架构简单多了。有些开发者可能有不同意见，他们可能会说，不是构建业务逻辑出了问题，而是它们与技术的结合，也就是实现环节出了问题。那么，接下来的问题就清晰了，我们构建业务逻辑为什么要受到技术因素的影响呢？这合理吗？难道它不是独立于技术而存在的吗？
只要跳出技术思维的窠臼（本质上是技术人员对掌握新技术的焦虑感），你就会发现，我们一直没有认真地考虑过构建业务逻辑这个问题，或者说脱离技术实现思考过这个问题。有一些显而易见的事实一直在我们眼前，却一直被忽视
