使用领域驱动设计时，共享不同项目的模型的最佳实践是什么？
因此，我们可以将领域驱动设计应用于多个项目，但同一部分领域模型可能存在交叉。
在这种情况下，如何应用领域驱动设计（使用ORM、模型优先、生成数据库模式）？创建具有许多相同表的多个数据库？或者如何共享数据？使用同义词？解决共享模型（包括数据）的可能策略是什么？
欢迎任何建议。提前致谢！
So we may apply the domain driven design for multiple projects but there could be intersection of the same piece of domain model.
In this case, how to apply the domain driven design (use ORM, model first, generating database schema)? Create multiple databases with a lot of same tables? Or how to share data? Use synonyms? What is the possible strategy to resolve the sharing model (including data)?
Any suggestion is welcome. Thanks in advance!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
在我之前的项目中，我们就多个具有共享部分的模型中的冗余信息进行了很多讨论。
我们发现有趣的是，我们认为几个项目（不是 C# 项目，而是真正的大型开发项目）或称为系统的项目很少在如何使用模型方面拥有完全相同的观点。我们认为，在跨越多个应用程序/系统/项目的更大域中，您可以发现多个核心，而您不希望这些核心在每个应用程序中重复。
这一切最终都形成了一个分布在多台机器上的域。我们有 GUID 密钥将它们在数据库中绑定在一起。但由于我们做了这个“模型优先”，子域就像通过域事件到达的基础设施相关服务一样相互查看。
复杂的？并不真地。这是一个例子：
领域一（薪资审核系统） - 我们有一个薪资审核统计系统，对员工的薪资及其与他们的经验、年龄和绩效的关系进行评估。核心是问卷形式、工作评价、问卷答案、评分。薪资修改建议等。
领域二（员工系统） - 在这里您管理员工，注册新员工，处理康复，也许是个人发展，薪资，员工合同，员工福利等。
领域三（绩效管理）- 在这里，您可以处理员工经验、目标、成就的历史，以及老板和员工之间关于个人发展、绩效评级和等级的协议。
正如您所注意到的，每个域的核心都是不同的，但它们有一些共同的关注点。根据部署、基础设施以及它们之间的关联/响应程度的要求，解决此问题的技术可能会有所不同。
我更喜欢独立进行这项技术。我们使用 NServiceBus 通过域事件（Udi Dahn 的域事件模式）来同步域。
例如，一旦我们完成了对员工的薪资审查，老板应该被告知乔今年应该有机会加薪 200 - 500 美元。
实体聚合根 Employee 上的方法 ApplySalaryReview 不仅保存审核结果，还会触发域事件 NotifySalaryReviewSubscribers，该事件会触发应用程序层中的事件处理程序 HandleNotifySalaryReviewSubscribersEvent，该事件处理程序在 ctor 中接受基础设施服务。该服务将结果放入消息队列中，所有需要此信息的系统都可以订阅此消息。
在我们的例子中，它是域二（员工系统）。员工系统导入结果并通知员工的老板他获得了即将与该特定员工进行的薪资谈判的新信息。
我希望我能对其中一种方法有所启发。还有很多其他方法...
In my previous project we had a lot of discussions regarding having redundant info in several models that have some shared parts.
What we found interesting is that we thought that several projects (not C# proj, but real large development projects) or call it systems very rarely share the exact same perspective on how using the model. We thought that in a larger domain that spans over several application/systems/projects you could spot several core's where you don't want the cores to be duplicated in each application.
It all ended up with a domain that where distributed on several machines. And we had GUID keys to bind them together in database. But since we did this "model first", sub domains looked at each other like infrastructure related services that where reached through Domain events.
Complicated? Not really. Here's an example:
Domain one (Salary review system) - We have a Salary Review statistic system which conduct evaluation on employees salary and how they related to their experience, age and performance. The Core is questionnaire form, work evaluation, questionnaire answers, rating. salary modification advices etc.
Domain two (Employee system) - Here you manage your employee, register new employees, handle rehab, maybe personal development, salary, employee contract, employee benefits etc.
Domain three (Performance management) - Here you handle history of employee experience, goals, achievements, and agreements between boss and employees about personal development, rating and grade of performance.
As you notice the Core of each domain is different but they share some concerns. Depending on deployment, infrastructure and requirement on how tight they should relate/respond to each other - the tech how to solve this could differ.
I Prefer to do this tech independent. We used NServiceBus for synchronizing domain through Domain Events (Udi Dahn's Domain Event Pattern).
For instance, Once we have completed a salary review for an employee and boss should be informed that Joe should get a chance of salary increase with 200 - 500 $ this year.
The method ApplySalaryReview on entity aggregate root Employee do not only save the review result, it also trigger domain event NotifySalaryReviewSubscribers which trigger an eventhandler HandleNotifySalaryReviewSubscribersEvent in Application layer that takes a infrastructure service in ctor. That service puts result in a message queue that all systems that need this info can subscribe on this message.
In our case, it is Domain two (Employee system). The employee system import result and notify employee's boss that he got new info for the upcoming salary talk with this particular employee.
I hope I may have shread some light on one way of doing it. There are so many other ways as well...
您可能想（重新）阅读蓝皮书。
You might want to (re-)read the strategic design patterns in the blue book.