Design patterns 在一个域模型中使用大量服务类是什么的标志

我最近试着练习DDD，我发现我自己倾向于使用很多域模型对象，这些对象是纯数据结构，没有行为，域模型中有很多服务，我想知道这是否是设计不好的迹象，架构的影响（实体框架）根据我的设计或使用错误的技术开发此类应用程序，我认为这是一个90%的CRUD应用程序。

如果应用程序确实是90%的CRUD，那么它就没有丰富的领域。DDD适用于丰富的域，可能不适合应用程序。正如第一条评论所指出的，您拥有的是一个贫血的域模型，在DDD的上下文中它被认为是一种反模式，但实际上对于大多数应用程序来说是足够的。Eric Evans在他的书中指出，DDD在大多数情况下是不必要的。

域服务的百分比不是衡量域模型质量的有用指标

但是，如果您需要域模型，“没有行为的纯数据结构”是

现在，如果应用程序处理的业务非常复杂，需要领域专家来理解，则需要领域模型。很少有应用程序需要DDD（Evans曾表示只有5%），但它们通常是高预算的。此类预算来自两个方面：业务的高度复杂性和利益相关者从中获得的竞争优势

即使域类在整个项目中所占的百分比也不是一个有用的指标：例如，在CQRS应用程序中，您将拥有许多DTO，但仍然可以拥有一个接收命令的良好域模型。此外，有一个90%的CRUD应用程序是很好的，它在一个有良好边界的操作上下文中需要一个域模型来强制执行复杂的业务不变量

然而，如果您不需要领域专家，您可能不需要领域模型

如果是这样，请记住，流行语驱动的开发非常昂贵。

---

您不应该“尝试”使用DDD。

如果您开始域设计时“忘记”了存在的实例，但最终仍然拥有90%的数据结构，那么很有可能您没有域，或者如果您知道确实存在可以建模的业务概念和流程，那么这就是过程代码的强烈气味。顺便说一句，DDD的核心意思是：根据业务流程设计应用程序，而不是根据db结构。实体、集合和其他花哨的词语只是细节。写得好的答案，关于这个确切的短语“Evans曾经只说了5%”，你能提供一个可靠的来源吗。另外，如果我不使用域模型，那么您使用什么技术来构建应用程序。你是走先构建数据库的老路，还是有其他我不知道的技术。我对一种适合CRUD应用的技术非常感兴趣。另一件事，如果我不使用域模型，并且项目发展到了无法管理的程度，我会不会被迫再次回到域模型，为充满问题的长篇评论感到抱歉？至于埃文斯的引用，我再也找不到那个视频了，抱歉。至于要走的路，最简单的可能可行的方法（我只在DDD是最简单的可行方法时才选择DDD）：有时它是数据驱动的，有时数据不是那么相关（数学引擎、游戏等等）。至于项目演化：业务复杂性指导了DDD的采用，但没有DDD并不意味着没有架构。请一位优秀的软件架构师，他将根据您可以合理预测的发展正确地设计应用程序。如果可能的话，我有兴趣与您进行一次简短的交谈，谢谢。这是关于有限上下文的一个很好的观点。另外10%可能确实需要一个域名。