多个服务使用的域模型？
我有一个域模型来处理投诉。许多功能需要向外界公开，因此我可以创建一个公开可用的 WCF REST 服务来实现此目的。其他功能仅用于内部目的（管理内容），因此我可以创建另一个内部托管的 WCF 服务来执行此操作。
结果是两个服务使用相同的域模型。
从技术上讲，这意味着两个可部署单元（服务）使用同一个类库 - 因此，如果类库发生更改，我必须部署这两个服务。
让一个变化很大的类库被超过 1 个可部署单元使用，这是一件坏事吗？我是否应该让外部服务使用内部服务而不是域模型，以便域模型仅由内部服务使用？
只是想知道最好的方法是什么，确保之后不存在技术问题（易于维护和部署）。感谢您的建议！
编辑：我决定这样做：公共服务将作为 WCF REST + JSON 公开，并且只负责将数据转换为移动应用程序所需的正确格式。此公共服务使用内部命令服务（具有完整域的 WCF）来执行命令，并使用内部查询服务（ADO.NET 数据服务）来执行查询。
I have a domain model to handle complaints. A number of functionalities need to be exposed to the outside world, so I can create a publically available WCF REST service to do that. Other functionalities are meant to be used for internal purposes only (admin stuff), so I can create another WCF service which is hosted internally to do that.
The result is that the same domain model is used by two services.
Technically this means that the same class library is used by two deployable units (the services) - so if the class library changes, I have to deploy the two services.
Is this a bad thing, to have a class library that changes a lot be used by more than 1 deployable unit? Should I maybe have the external service use the internal service instead of the domain model, so that the domain model is only used by the internal service?
Just wondering what the best approach would be, making sure that there are no technical issues afterwards (easy maintenance and deployment). Thanks for the advice!
EDIT: I decided to do it as follows: the public service will be exposed as WCF REST + JSON, and will have only the responsibility to transform data into correct format needed by mobile application. This public service uses the internal command service (WCF with full domain) to execute commands and the internal query service (ADO.NET data service) to do queries.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
让一个变化很大的类库被多个可部署单元使用，这是一件坏事吗？
它可能会产生管理问题，但有时这是不可避免的，特别是对于共享库。但是，当您处理域模型时，最好限制公开模型功能的服务数量。我喜欢您提出的让外部服务引用内部服务的解决方案。然后，外部服务在内部服务之上提供某种外观，而内部服务则专注于公开域的功能。然而，正如 Thomas Jaskula 指出的那样，评估服务的行为方面非常重要。外部服务是从内部服务中公开一组有限的功能，还是同时提供不同的功能？什么是有界上下文？
Is this a bad thing, to have a class library that changes a lot be used by more than 1 deployable unit?
It can create management issues, but sometime is is unavoidable, especially for shared libraries. However, when you are dealing with a domain model it is best to limit the number of services which expose the functionality of the model. I like your proposed solution of having the external service reference the internal service. Then the external service provides a sort of facade over the internal service, and the internal service is focused on exposing the functionality of the domain. However, as pointed out by Thomas Jaskula, it is important to evaluate the behavioral aspect of the services. Is the external service exposing a limited set of functions from the internal service or is it providing different functionality all together? What are the bounded contexts?
我不确定我们是否在谈论领域驱动设计，但从您的描述来看，它不适合我。 DDD 涉及行为，而不仅仅是实体和值对象。
外部用户可以通过 WCF REST Api 与您的域进行的交互与管理员可以进行的交互不同。因为行为可能不一样。然后对我来说，从领域模型的角度来看，您必须对您尝试解决的每个问题（WCF 和管理）进行建模。所以有两个模型。
在 DDD 中，不只有一种模型可以处理业务问题。
但是，如果您的域只是一个抽象和持久性（哑实体），您可以在这两个项目中使用它。但即使如此，我也会创建两个不同的模型以避免部署问题，并且根据上下文，您可能不会一直使用相同的实体。
这只是我对此的看法。
I'm not sure if we're talking about Domain-Driven-Design but from what you're describing it is not for me. DDD is about behaviour and not just entities and value objects.
The interaction that external users could have with your domain through the WCF REST Api is not the same that the admins could have. Because the behaviour is likely not the same. Then for me from the point of view of the domain model you have to model each problem that you try to solve at the hand (WCF and admin). So two models.
In DDD there is no just one model to handle or business issue.
But, if your domain are just an abstraction od persistance (dumb entities) you could use it in both projects. But even for that I would create two different models to not have the deployement issues, and your likely to not use the same entites all the time depending on context.
This is just my take on that.