如何在 .Net 中正确实现共享内核 (DDD)
我正在重新设计一个旧版应用程序，因为此时它就是我们所说的“泥球”，根本没有分层或 SOC。该团队习惯于模块化工作，这意味着有一个团队负责“培训”、“工作机会”，一个团队负责管理“职责规划（军事）”的模块。我们有一个网站向我们的客户展示这些领域作为服务门户、一个数据库和我们服务的一些外部应用程序。
除了如何正确划分域之外，我重新设计了大部分层，做得很好（此时我应该提到我们正在使用 .Net 4.0）。我最初的想法是，由于它们的工作方式，这些是有界上下文，它们似乎确实有不同的用户组，但我相信现在的现实是使用该网站的人可能并且确实同时使用多个区域。当然，有些团体只使用一项服务，但很多团体使用多种服务。网站的目标是“会员”的一站式管理。在模块之间，我们有模块独有的类，然后我们有一些共享的类，例如，成员的概念是所有模块都知道并使用的。会员实际上是一个核心概念，网站通过同时跟踪会员在所有这些方面的信息来增加价值。基本上就是这样，系统中一些密切相关但独立的区域和共享区域。我希望这足够清楚地回答我的问题。
我想我仍然会有一个共享内核，即使这些不是有界上下文，用于公共实体和共享域接口，例如通用存储库接口。将所有通用代码（通用存储库、核心域模型、共享内核等）放入相同的命名空间或命名空间层次结构中是否明智，并且我应该在它自己的程序集中隔离该命名空间吗？同样，我是否会将每个区域（“培训”、“机会”...）分解为它们自己的程序集，或者最好将它们全部放在一个程序集中并按命名空间对它们进行逻辑分区。一方面，更容易看到模块的物理分区，但我担心两个模块需要一起工作来解决问题的情况。他们将如何通信并保持事物非循环（我猜测是通过应用程序层中的服务）。
so（选项摘要）：
Domain.Model (dll) -- 域.模型.核心 -- 内核（共享实体和核心域模型） -- 存储库框架 - ETC... -- 领域.模型.训练 -- 领域.模型.机会 ...
或
Domain.Model.Core
Domain.Model.Training (dll)
Domain.Model.Opportunities (dll) （培训和机会如何协同工作？）
非常感谢您抽出时间，
I have a legacy app I am redesigning because it's what we call a "ball of mudd" at this point, no layering or SOC at all. The team is used to working modularly, meaning there is a team that works on "training", "Job Opportunities", one that works on a module managing "Duty Planning (military)". We have one website exposing these areas to our clients as a portal of services, one database and a few external apps we service.
Im doing well redesigning most of the layers except how to partition the domain properly (I should mention at this point that we are using .Net 4.0). My original thought was that these were bounded contexts because of the way they were working, they really seemed to have different sets of users, but I believe now the reality is people who use this site may and do use many areas at once. Sure, some groups ONLY use one service exclusively, but a lot use several. The goal of the site is one-stop management of "members". Between the modules we have classes unique to the module and then we have some shared classes, for example, the concept of a member is known and used by all modules. Member is actually a core concept, the site adds value by tracking member's information in all these areas at once. That's basically it, a few closely related but separate areas in the system and a shared area. I hope that is clear enough to answer the question I have.
I am thinking I would still have a shared kernel, even if these are not bounded contexts, for the common entities and shared domain interfaces such as a generic repository interface. Would it be wise to put all the common code (generic repository, core domain model, shared kernel etc) into the same namespace or namespace hierarchy and should I isolate this namespace in it's own assembly? Likewise, would I then break out each area ("training", "Opportunities"...) into their own assemblies or is it better to have them all in one assembly and logically partition them by namespace. On one hand, it's a bit easier to see the modules physically partitioned, but I am worried about situations where two modules need to work together to solve a problem. How would they communicate and keep things acyclic (through services in the application layer I am guessing).
so (summary of options):
Domain.Model (dll)
-- Domain.Model.Core
-- Kernel (shared entities and core domain model)
-- RepositoryFramework
-- etc...
-- Domain.Model.Training
-- Domain.Model.Opportunities
...
or
Domain.Model.Core
Domain.Model.Training (dll)
Domain.Model.Opportunities (dll)
(how do training and opportunities work together?)
Thank you very much for your time,
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
在物理布局的情况下，我会将所有内容（整个域模型）放在一个程序集中。使用单独的程序集不会给您带来任何好处，反而会使事情变得复杂并增加编译时间。
另一方面，如果存在某些开发人员使用不适当的类（属于其他模块/上下文的类）的风险，则明智的做法是将逻辑拆分为公共程序集（核心域、共享内核）和特定于每个模块/上下文。
对于逻辑布局（命名空间），我会给每个部分一个单独的命名空间（例如 DomainModel.Core、DomainModel.Training）。有时，明智的做法是更进一步，将每个聚合放入其自己的命名空间中。它可以防止意外跨越聚合边界，因为它需要单独的“using”指令。
希望这是有道理的。
In case of physical layout, I would put everything (the whole domain model) in one assembly. Using separate assemblies does not give you any benefit while it complicates things and increases compilation time.
On the other hand, if there is a risk that some developers use inappropriate classes (those who belong to other modules/contexts), it may be wise to split the logic into a common assembly (core domain, shared kernel) and assemblies specific to each module/context.
In the case of the logical layout (namespaces) I would give each part a separate namespace (for example DomainModel.Core, DomainModel.Training). Sometimes it is wise to go one step further and put each Aggregate into its own namespace. It prevents accidental crossing of the aggregate boundaries since it requires a separate 'using' directive.
Hope that makes sense.