我经常读到，当团队无法访问域专家时，您不应该执行DDD。 但是，如果域名不是微不足道但没有域专家可用，团队只能访问代理域专家或仅访问产品所有者，那么DDD的替代方案是什么。
在这种情况下，团队是否应该在团队中创建共同语言，在有界上下文中创建域模型，使用聚合和聚合根来强制执行业务约束，使用存储库来确保模型的持久性无知等等？ / p>
我知道DDD不是一个整体或没有，并且它没有描述一个架构 但是一种设计方法。但是，如果域名专家不可用，那么在复杂域名的情况下使用DDD的战术模式和战略设计是不是会产生影响？当没有领域专家可用时，我不会使用哪部分DDD？
答案 0 :(得分：5)
您实际需要的是域专家作为角色，不一定是具体的物理人（除了一个或多个开发团队成员） 。拥有一个“真正的”领域专家是可取的，但并非总是可行。在这种情况下，开发团队必须积累专家领域知识 - 我知道这不完美，但完全可能（在实践中并不罕见）。
答案 1 :(得分：2)
首先，我还没有看到当团队无法访问域专家时您不应该执行DDD。
域模型和域驱动设计的主要优点是使用Ubiquitous Language。它是“开发人员和用户之间通用，严谨的语言”。
它用于解决开发人员和企业之间的误解。
当一个项目的语言断裂时，它将面临严重的问题。领域专家使用他们的行话，而技术团队成员有自己的语言调整在设计方面讨论域。日常讨论的术语与代码中嵌入的术语（最终是软件项目中最重要的产品）脱节。即使是同一个人在言语和写作中使用不同的语言，......
开发团队或业务客户端应该使用相同的词汇表来处理项目。
使用该模型作为语言的支柱。让团队在团队内部和代码中的所有沟通中坚持不懈地运用该语言。在图表，书写，尤其是语音中使用相同的语言。
认识到语言的变化是对模型的改变。
在您的情况下，只需“访问代理域专家或仅访问产品所有者即可。
在Scrum流程中Product Owner (PO) is a bridge between development team and stakeholders。
当开发团队使用Ubiquitous Language执行业务时，执行业务分析的开发人员和业务人员/ PO一起构建此语言时，这种情况很常见。
有时，企业对单个“实体”或“流程”或“功能”有多个术语，选择正确的一个术语是一个挑战。
第二，由于团队负责制定架构决策和设计应用程序，因此在合理的情况下，他们可以 "create a common language across the team, create a domain model within bounded contexts, use aggregates and aggregate roots to enforce business constraints, use repositories to ensure persistence ignorance for the model, etc" 。
第三，我认为做或不做DDD的决定取决于软件的要求，而不依赖于域专家的可用性。