域服务层的良好命名

Question

抽象

哪个名字更好？

• Domain.PersonService
• DomainServices.PersonService
• DomainServices.PersonDomainService(考虑一些较长的名字PersonDomainServiceModelDecorator)

或者是其他东西？

情况

我们有一个框架,每个层都有一些基类.防爆.存储库,域服务,UI等

每个逻辑层都有一个名称,用作其名称空间:

• 包含存储库的数据层的"数据"; 防爆.Fx.Data.DbContextRepository
• 域(非Web)服务层的"服务"; 防爆.Fx.Services.CrudService
• Web UI层的"Web.UI"; 防爆.Fx.Web.UI.Controllers.CrudController

对于一些额外的层,我们也遵循相同的终端项目规则:

• "数据"Ex. Project.Data.PersonRepository
• "服务"Ex. Project.Services.PersonService
• "Web.UI"Ex. Project.Web.UI.Controllers.PersonController
• 代码优先实体的"实体"; 防爆.Entities.Person
• 对象模型的"模型"; 防爆.Models.Person.Criteria,Models.Person.PersonDeleteModel

我的重点是"域名服务"层,但欢迎任何关于其他层的想法.

我们最终得出的结论是"服务"不是"域服务"的合适名称,因为它可能导致"Web服务"或"域服务"层之间的歧义.

现在我们将"服务"命名空间更改为"域"或"域服务".但我们还有另一个问题.我们为每个域服务类(例如PersonService)添加了"服务"后缀.现在,使用"DomainService"后缀(例如DomainServices.PersonDomainServer或者DomainServices.DomainPersonService)似乎很难看.

因此,使用"Domain"作为命名空间可能更漂亮,而类名称显示它们是域命名空间(Ex.Domain.PersonService)下的服务.

Answer 1

我会提出两个简单的想法:

1. 尝试定义没有冗余的全名(名称空间+类型名称)(同一名称部分 - 域,人,服务,模型,控制器,...... - 不应出现两次)尽可能

2. 从.NET框架本身获得灵感.那里有40000多个班级!打开.NET Reflector或ILSpy等工具中的所有程序集,并仔细研究它.

我想出这样的事情:

Domain
 + Person
 + PersonService // Domain service
Domain.Data
 + PersonRepository
Domain.ServiceModel // WCF, etc. I chose the same namespace as .NET Framework
 + PersonService // Service implementation, this is really a service so "service" redundancy seems unavoidable here
Domain.Web.UI
 + PersonController

好吧,它显然不方便在层次结构中多次出现相同的类型名称.好吧,但这也是名称空间(和命名空间别名)也存在的原因.我认为这不是什么大问题.

Answer 2

您认为您的项目之间有什么区别Domain吗DomainServices？如果您想将服务和其他域实体保留在单独的命名空间中，我相信您将需要移动PersonService到DomainServices命名空间。

大多数时候我们不研究名称空间，我们只提到类，这就是为什么我认为拥有DomainServices名称空间很好。同时，如果您在整个应用程序中有单个域并且没有计划将其分离，我认为最好调用它Domain.PersonService

关于类名中的“Doman”一词，我真的不喜欢这个，因为它增加了名称的复杂性。您应该尝试以这种方式构建您的应用程序，以确保您打开时PersonService应该 100% 确定它是域服务。你知道，当你打开时PersonRepository，它是Data层，对于域也是如此。