有人能举例说明域服务和应用程序服务之间的区别吗?而且,如果一个服务是一个域服务,我是否会将该服务的实际实现放在域程序集中,如果是的话,我是否也会将存储库注入到该域服务中?一些信息会很有帮助。
当前回答
服务有三种类型:域服务、应用服务和基础设施服务。
域服务:封装 业务逻辑并不自然 适合于域对象,并且不是典型的CRUD操作——那些属于存储库。 应用程序服务:由 外部消费者与你交谈 系统(考虑Web服务)。如果使用者需要访问CRUD操作,它们将在这里暴露。 基础设施服务:习惯 抽象的技术问题(例如: MSMQ,电子邮件提供商等)。
把域服务和域对象放在一起是明智的——它们都关注域逻辑。是的,您可以将存储库注入到服务中。
应用程序服务通常会同时使用域服务和存储库来处理外部请求。
其他回答
从红皮书(实现领域驱动设计,由Vaughn Vernon)中,我是这样理解这些概念的:
域对象(实体和值对象)封装了(子)域所需的行为,使之自然、有表现力和可理解。
域服务封装了这些不适合单个域对象的行为。例如,一个图书馆可以通过域服务将图书借给客户端(带有相应的库存更改)。
应用程序服务处理用例流,包括域之上所需的任何附加关注点。它经常通过API公开这样的方法,供外部客户端使用。基于前面的例子,我们的应用程序服务可能会公开一个方法LendBookToClient(Guid bookGuid, Guid clientGuid):
Retrieves the Client. Confirms its permissions. (Note how we have kept our domain model free of security / user management concerns. Such pollution could lead to many problems. Instead, we fulfill this technical requirement here, in our application service.) Retrieves the Book. Calls the domain service (passing the Client and Book) to handle the actual domain logic of lending the book to the client. For instance, I imagine that confirming the book's availability is definitely part of the domain logic.
应用程序服务通常应该具有非常简单的流程。复杂的应用程序服务流通常表明域逻辑已经泄漏出域。
正如您所希望看到的,领域模型以这种方式保持非常干净,并且易于理解并与领域专家讨论,因为它只包含它自己的实际业务关注点。另一方面,应用程序流也更容易管理,因为它消除了领域问题,变得简洁明了。
Domain Services : Methods that don’t really fit on a single entity or require access to the repository are contained within domain services. The domain service layer can also contain domain logic of its own and is as much part of the domain model as entities and value objects. Application Services : The Application service is a thin layer that sits above the domain model and coordinates the application activity. It does not contain business logic and does not hold the state of any entities; however, it can store the state of a business workflow transaction. You use an Application service to provide an API into the domain model using the Request-Reply messaging pattern.
米勒特,C(2010)。专业的ASP。NET设计模式。威利出版。92。
服务有三种类型:域服务、应用服务和基础设施服务。
域服务:封装 业务逻辑并不自然 适合于域对象,并且不是典型的CRUD操作——那些属于存储库。 应用程序服务:由 外部消费者与你交谈 系统(考虑Web服务)。如果使用者需要访问CRUD操作,它们将在这里暴露。 基础设施服务:习惯 抽象的技术问题(例如: MSMQ,电子邮件提供商等)。
把域服务和域对象放在一起是明智的——它们都关注域逻辑。是的,您可以将存储库注入到服务中。
应用程序服务通常会同时使用域服务和存储库来处理外部请求。
域服务是域的扩展。应该只在域的上下文中看到它。这不是像关闭帐户之类的用户操作。域服务适用于没有状态的地方。否则它就是一个域对象。域服务只有在与其他协作者(域对象或其他服务)合作时才有意义。这是另一层人的责任。
Application service is that layer which initializes and oversees interaction between the domain objects and services. The flow is generally like this: get domain object (or objects) from repository, execute an action and put it (them) back there (or not). It can do more - for instance it can check whether a domain object exists or not and throw exceptions accordingly. So it lets the user interact with the application (and this is probably where its name originates from) - by manipulating domain objects and services. Application services should generally represent all possible use cases. Probably the best thing you can do before thinking about the domain is to create application service interfaces what will give you a much better insight in what you're really trying to do. Having such knowledge enables you to focus on the domain.
一般来说,存储库可以被注入到域服务中,但这种情况相当罕见。不过,大多数时候是应用层在做这件事。
域服务:表示不属于任何聚合根的业务逻辑的服务。
You have 2 Aggregate: Product which contains name and price. Purchase which contains purchase date, list of products ordered with quantity and product price at that time, and payment method. Checkout is not part of either of these two models and is concept in your business. Checkout can be created as a Domain Service which fetches all product and compute the total price, pay the total by calling another Domain Service PaymentService with an implementation part of Infrastructure, and convert it into Purchase.
应用程序服务:“编排”或执行域方法的服务。这可以像你的控制器一样简单。
这是你经常做的事情:
public String createProduct(...some attributes) {
if (productRepo.getByName(name) != null) {
throw new Exception();
}
productId = productRepository.nextIdentity();
product = new Product(productId, ...some attributes);
productRepository.save(product);
return productId.value();
// or Product itself
// or just void if you dont care about result
}
public void renameProduct(productId, newName) {
product = productRepo.getById(productId);
product.rename(newName);
productRepo.save(product);
}
您可以在这里进行验证,例如检查Product是否惟一。除非产品是唯一的,否则它应该是域服务的一部分,可能被称为UniqueProductChecker,因为它不能是产品类的一部分,它与多个聚合进行交互。
下面是DDD项目的完整示例:https://github.com/VaughnVernon/IDDD_Samples
你可以找到很多应用程序服务和一些域服务的例子
推荐文章
- Symfony 2.x中的所有东西都应该捆绑吗?
- 用Python构建最小的插件架构
- 单页应用:优点和缺点
- 什么是领域驱动设计?
- 由Jon Skeet撰写的《Singleton》澄清
- DDD -实体不能直接访问存储库的规则
- 跨REST微服务的事务?
- 为什么Linux被称为单片内核?
- 你如何设计面向对象的项目?
- “Layers”和“Tiers”的区别是什么?
- 一般来说,在一个组件中使用一个还是多个useEffect钩子更好?
- 何时以及如何在微服务架构中使用GraphQL
- 服务应该总是返回dto,还是也可以返回域模型?
- “协程”和“线程”之间的区别?
- 当Node.js内部仍然依赖线程时,它是如何固有地更快的?