我有一个遗留的应用程序我正在重新设计,因为这就是我们所谓的"混乱之球",没有任何分层或SOC.该团队习惯于模块化工作,这意味着有一个团队致力于"培训","工作机会",一个工作在管理"职责规划(军事)"的模块.我们有一个网站向我们的客户公开这些区域作为服务门户,一个数据库和我们服务的一些外部应用程序.
我正在重新设计大多数层,除了如何正确地分区域(我应该在这一点上提到我们正在使用.Net 4.0).我最初的想法是,这些都是有限的背景,因为他们的工作方式,他们似乎真的有不同的用户组,但我相信现在现实是使用这个网站的人可能并且确实同时使用许多区域.当然,有些团体只使用一项服务,但很多人使用多项服务.该网站的目标是"成员"的一站式管理.在模块之间,我们有模块特有的类,然后我们有一些共享类,例如,成员的概念是已知的并且被所有模块使用.会员实际上是一个核心概念,该网站通过在所有这些领域同时跟踪会员的信息来增加价值.基本上就是它,系统中的一些密切相关但分开的区域和共享区域.我希望这很清楚,可以回答我的问题.
我认为,对于公共实体和共享域接口(如通用存储库接口),我仍然会有一个共享内核,即使它们不是有界上下文.将所有公共代码(通用存储库,核心域模型,共享内核等)放入相同的命名空间或命名空间层次结构中是否明智？我应该在其自己的程序集中隔离此命名空间吗？同样,我是否会将每个区域("训练","机会"......)分解为自己的程序集,或者将它们全部放在一个程序集中并按命名空间对它们进行逻辑分区更好.一方面,看到模块物理分区更容易一些,但我担心两个模块需要协同工作来解决问题的情况.他们将如何沟通并保持非循环(通过我猜测的应用层中的服务).
所以(选项摘要):
Domain.Model(dll) - Domain.Model.Core - 内核(共享实体和核心域模型) - RepositoryFramework - etc ... - Domain.Model.Training - Domain.Model.Opportunities ...
要么
Domain.Model.Core
Domain.Model.Training(dll)
Domain.Model.Opportunities(dll)(培训和机会如何协同工作？)
非常感谢您的宝贵时间,