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.
我有一个我正在重新设计的遗留应用，因为它就是我们现在所说的“mudd之球”，根本没有分层或SOC。该团队习惯于模块化工作，这意味着有一个团队负责“培训”、“工作机会”，一个团队负责管理“任务规划(军事)”模块。我们有一个网站将这些领域作为服务门户向客户开放，一个数据库和一些我们服务的外部应用。
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.
我很好地重新设计了大多数层，除了如何正确地划分域(我应该在这一点上提到我们正在使用。net 4.0)。我最初的想法是，这些是有界的上下文，因为它们的工作方式，它们看起来确实有不同的用户集，但是我相信现在的现实是，使用这个网站的人可能同时也确实使用了许多领域。当然，有些组只使用一个服务，但很多组只使用几个。网站的目标是“会员”的一站式管理。在模块之间，我们有模块特有的类，然后我们有一些共享类，例如，成员的概念是所有模块都知道并使用的。成员实际上是一个核心概念，站点通过跟踪成员在所有这些区域的信息来增加价值。基本上就是这样，系统中一些密切相关但又独立的领域和一个共享领域。我希望这足够清楚地回答我的问题。
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 ...
域。模型(dll)——Domain.Model。Core——内核(共享实体和核心域模型)——RepositoryFramework——等等。——Domain.Model。培训——Domain.Model。机会……
or
或
Domain.Model.Core
Domain.Model.Core
Domain.Model.Training (dll)
Domain.Model。培训(dll)
Domain.Model.Opportunities (dll) (how do training and opportunities work together?)
Domain.Model。机会(dll)(培训和机会如何一起工作?)
Thank you very much for your time,
非常感谢您的时间，
1 个解决方案
#1
3
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 increase compilation time.
对于物理布局，我将把所有东西(整个域模型)放在一个程序集中。使用单独的程序集不会给您带来任何好处，但会使事情变得复杂并增加编译时间。
On the other hand, if there is a risk that some developers use inappropriate classes (those who belong to other module/context), it may be wise to split the logic into common assembly (core domain, shared kernel) and assemblies specific to each module/context.
另一方面，如果有一些开发人员使用不合适的类(属于其他模块/上下文的类)的风险，那么最好将逻辑分割为公共程序集(核心域、共享内核)和特定于每个模块/上下文的程序集。
In case of 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 from accidentally crossing the aggregate boundaries since it requires a separate 'using' directive.
在逻辑布局(名称空间)的情况下，我将为每个部分提供一个单独的名称空间(例如DomainModel)。核心,DomainModel.Training)。有时更进一步，将每个聚合体放入自己的名称空间中是明智的。它可以防止意外地跨越聚合边界，因为它需要一个单独的“使用”指令。
Hope that makes sense.
希望是有意义的。
#1
3
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 increase compilation time.
对于物理布局，我将把所有东西(整个域模型)放在一个程序集中。使用单独的程序集不会给您带来任何好处，但会使事情变得复杂并增加编译时间。
On the other hand, if there is a risk that some developers use inappropriate classes (those who belong to other module/context), it may be wise to split the logic into common assembly (core domain, shared kernel) and assemblies specific to each module/context.
另一方面，如果有一些开发人员使用不合适的类(属于其他模块/上下文的类)的风险，那么最好将逻辑分割为公共程序集(核心域、共享内核)和特定于每个模块/上下文的程序集。
In case of 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 from accidentally crossing the aggregate boundaries since it requires a separate 'using' directive.
在逻辑布局(名称空间)的情况下，我将为每个部分提供一个单独的名称空间(例如DomainModel)。核心,DomainModel.Training)。有时更进一步，将每个聚合体放入自己的名称空间中是明智的。它可以防止意外地跨越聚合边界，因为它需要一个单独的“使用”指令。
Hope that makes sense.
希望是有意义的。