盛安德分享：我们如何从DDD中受益？

DDD原则是开发软件需要从业务需求开始。通常倾向于关注技术细节，但通过这种模式，设计基于核心业务目的和逻辑，同时可考虑到公司的战略方向。企业应用程序可能非常复杂，因此我们的团队使用了一种将用户（领域专家）连接到需求定义的开发技术，目的是构建可转换为解决业务需求的软件。
在本文中，我想分享一下我们如何从领域驱动设计中受益的经验

在我遇到领域驱动设计之前
在Shinetech，我们多年来一直从事敏捷实践，Scrum已成功应用于我们的大多数项目中。由于行业敏捷大师和国内优秀软件工程师的共享和推动，我们使用了许多优秀的软件开发实践，如TDD，BDD，CI等，所有这些都为我们带来了巨大的利益。由于我们主要专注于为客户开发项目，尽管这些实践可以提高软件交付质量和开发效率，但如果我们想以最佳方式使用它们，它实际上涉及很多因素。以一些常见的场景为例：

• Scrum项目需要产品负责人Product Owner角色，但客户很少有这样的角色与Scrum定义相一致 。
• BDD对客户的需求甚至更高，他们需要编写具体，情景，给定......当......然后。我经历了一个项目，客户在开始时写了BDD，真正的高质量BDD，然而，他停止写它，因为他认为它太麻烦了。
• 在我们的项目中主要使用.NET，尽管每个人都熟悉面向对象，类，接口，继承，封装等，但在涉及如何正确地抽象业务或使用时，对我们来说仍然是一个巨大的挑战。以正确的方式面向对象。
• 使用敏捷方法时，与传统的开发过程不同，后者提供详细的需求规范（假设规范及时更新，描述准确且易于理解），敏捷强调可行的软件。但是，正如我们所知，有很多业务逻辑难以通过界面反映，即使有用户故事，PO产品负责人很难编写与SMART规则一致的用户故事，常见的情况是通常像这样 - PO表达了一个粗略的想法或要求场景，程序员“立即明白了这个想法”，他们最终开发了一个通过验收测试的软件，但是，因为有测试和反馈修复，这些要求实际上“丢失了” ”。
• 资源变化是软件行业中的常见现象，但通常小团队中没有备用资源，因此当资源发生变化时，如果没有好的方法进行知识转移，项目相关的上下文很容易丢失; 即使人们试图在知识转移方面做得很好，它仍然存在很大的挑战，因为当人们决定离开时，他的思绪首先如何离开并且难以专注于当前的工作，所以我们能做的就是尽力减少因为项目相关的背景导致的损失。

在我建立Shinetech西安分公司的前几年，我致力于在我们的分公司进行敏捷实践和其他良好的软件开发实践，我们从中受益匪浅 - 我们团队的软件技能得到了很大提高，他们熟悉了有很多清洁代码的东西，了解单元测试，CI，GitFlow等的重要性和好处。但是，我也同时考虑以下问题：

1. 如何减少客户反馈中的错误？虽然敏捷强调经常与客户进行互动和反馈，以便在开发过程中尽早出现错误，而不是通过多次修改获得正确的结果，但首先做正确的事情肯定会提高项目交付速度，这也可以节省成本我们的客户，提高我们的程序员的效率。
2. 资源变化过程中的知识转移。虽然我们可以通过清晰的软件架构，清晰的代码和高单元测试覆盖率来高度提高新资源对项目的理解速度，但是新的人力资源仍然需要很长时间才能读懂用户故事、单元测​​试和各种分布在不同级别中的代码（各个级别代码都有相关负责单位，但这并不意味着我们不需要单位责任）。
3. 开发人员的软件技能，工作效率和生产力的提高，以及开发人员薪水的提升，我认为这是我作为分公司经理的首要责任。从其他方面来说，我认为一些相对简单的项目，如CRUD项目，或者一些前端项目，如Angular / React项目，在市场上的能力会越来越低（我并不是要贬低前端，只是意味着进入这种已经存在的框架的门槛比较低）。因此，我们应该选择更加“艰难”的项目 - 具有复杂业务和需求的项目，只有这些类型的项目可以快速提高开发人员的能力并增加他们的费率促销的可能性。