所以,我在这里查看了一些关于规范模式的帖子,但还没有找到答案.
我的问题是,在一个n层架构中,我应该在哪些规范中获得"新建"？
我可以将它们放在我的服务层(也就是说,应用层,它有时被称为......基本上,.aspx代码隐藏的东西会与之交谈),但我觉得通过这样做,我让业务规则漏掉了域名.如果以其他方式(除了服务层)访问域对象,则域对象无法强制执行自己的业务规则.
我可以通过构造函数注入将规范注入到我的Model类中.但同样,这感觉"错误".我觉得唯一应该注入Model类的是"服务",比如缓存,日志记录,脏标记跟踪等等......如果你能避免它,那么使用Aspects而不是乱丢模型的构造函数具有大量服务接口的类.
我可以通过方法注入(有时称为"Double Dispatch")注入规范,并明确地使用该方法封装注入的规范以强制执行其业务规则.
创建一个"域服务"类,它将通过构造函数注入获取规范,然后让服务层使用域服务来协调Domain对象.这对我来说似乎没问题,因为规范强制执行的规则仍然在"域"中,而Domain Service类的命名方式与它正在协调的Domain对象非常相似.这里的事情是我觉得我正在编写大量的类和代码,只是为了"正确"实现规范模式.
除此之外,相关规范要求存储库以确定它是否"满意".
这可能会导致性能问题,尤其是 如果我使用构造函数注入b/c消耗代码可以调用一个可能包装规范的属性,并且反过来调用数据库.
所以任何想法/想法/链接到文章？
新产品和使用规格的最佳位置在哪里？
domain-driven-design specification-pattern n-layer application-layer