DDD领域服务

当我们开始编写软件时，我们总是希望有一个好的设计。我们阅读书籍，运用最佳实践，最后，我们常常一团糟。根据我在一家定制软件开发公司的经验，我每天必须处理此类代码，尤其是在某些旧系统上工作时。造成这种情况的原因多种多样，我将尝试在一系列文章中以一些实际的方式来探讨其中的一些原因。在我的第

许多年前，我们开始了一个新的长期项目，首先，我们基于洋葱架构构建了它的架构。在几个月内，这种风格开始显示出裂缝，我们从这种架构转向CQRS。随着转向CQRS，我们开始围绕垂直切片而不是层（无论是平面还是同心，它仍然是层）构建我们的架构。从那以后，在过去7到8年左右的时间里，围绕垂直切片架构构

在企业应用程序中，大多数处理是以同步方式完成的。客户端调用业务服务并等待业务服务从处理返回。但是，某些用例中的业务处理需要相当多的时间和资源。业务处理甚至可能跨越应用程序，可能与企业内外的应用程序集成。对于这些长期存在的进程，应用程序客户端等待业务处理完成是不可行的，在这种情况下，我们希望异

架构模块正如我们已经指出的那样，大多数DDD系统可能会使用OO范例。因此，我们对领域模型的元素可能很​​熟悉，例如实体，值对象和模块。例如，如果您是Java程序员，那么将DDD实体视

很多MVVM的问题通常是相同的：什么应该是模型，什么应该是ViewModel？我们不能真正责怪开发人员，因为在线参考文档不是很好，特别是

著名DDD社区意见领袖Nick Tune撰文认为微服务就是领域服务，建议使用领域服务替代微服务，banq赞成这种做法，在我的DDD书籍中已经将这两个概念混为一谈，当然他们还是有细微差别，比如微服务可能有关技术或应用方面功能例如增删改查CRUD可以在微服务中实现，但是不是好的领域服务功能，因为

计划任务一般都喜欢使用Cron作业来完成，比如使用spring scheduler或Quartz，本模式推荐使用黑盒式的不可知事件替代Cron作业。 问题许多业务流程涉及需要在将来执行的某些操作或工作或工作

许多软件架构试图将域逻辑与应用程序的其他部分分开。为了遵循这种做法，我们总是需要知道什么是领域逻辑，什么不是。不幸的是，这并不总是那么容易分开。如果我们做出错误的决定，领域逻辑很容易泄漏到其他组件和层中。我们将通过查看使用六边形应用程序架构的示例来解决这个问题。 假设

如果要编写可长期维护的应用程序，则必须与框架，ORM，HTTP客户端等分离，因为技术在发展，您的业务应用无法永远一直使用它们。 三个简单的规则要完成框架解耦，您只需遵循以下简单规则：所有服务都应获取其所有依赖项和配置值

使用应用程序控制器集中检索和调用请求处理组件，如命令和视图。让我们用例子来讨论应用程序控制器设计模式是如何工作的。 问题您希望集中并模块化操作和视图管理。在表示层中，通常在每个请求到达时要做

问题：什么对象应该有责任，当你不想使高凝聚力和低耦合时，但其他原则提供的解决方案不合适？解决方案：将一组高度凝聚力的责任分配给脚手架或帮助类之类工具，这些工具并不代表问题域中的概念。有时候很难弄清楚应该在哪里放置责任。这就是领域驱动设计中存在领域服务概念的原因。领域服务保存与

这篇文章用生物学概念来帮助你理解DDD设计中聚合服务等概念，细胞组成生物，生物组成社会。 细胞也称聚集如果我们看一个细胞，它可能是表示聚合的一个很好的比喻，为什么这样？细胞有边界（甚至是物理

我看过 ddd 领域服务的例子，比如验证，但在cqrs中验证好像不属于领域 write范围内，所以也就不需要领域服务，我也想不出在cqrs那些需要用到 领域服务。 多说用到 saga而已。

Netflix 是迈向实时数据基础设施的公司的典范 ，这使得 Netflix 能够通过多种方式改善用户体验，例如改进“Trending Now”主屏幕上的推荐、快速测试生产中的更改以及最大限度地减少 Netflix 服务的停机时间。 数据处理领域的

来自Google测试博客的文章：使用领域对象编写可适应变化的代码 尽管产品的需求可能经常变化，但其基本理念通常变化缓慢。这导致一个有趣的见解：如果我们编写的代码符合产品的基本理念，它将更有可能在未来的产品变化中生存下来。