我正在研究一个大型配置驱动的数据管理系统.通过在外部语法中指定配置(如业务规则,进程和验证)来构建系统.我们只想说语法是基于Groovy的DSL和Drools的集合体.
我喜欢DDD提供的简单性概念,特别是将基础架构问题与域的核心概念分离开来.
但是,由于系统的可配置性,我正在努力应用DDD的一些概念.行为(流程),验证和业务规则都是在系统外部定义的.因此,域中的实体本质上没有自己的行为.相反,它们对“验证器”或“规则引擎”或“工作流引擎”很敏感.
我将以一个例子来澄清.假设我的系统管理公司的员工.没有太多想法,您可以想象我的域中有员工实体和公司实体.
在DDD之后,我试图模拟一个员工晋升的场景.您可能会在Employee上看到一个名为promote(Employee.promote)的新方法.我们可以有一个业务规则,表明员工在同一年内不能被提升两次(是的,这一切都已完成).因此我可以这样：
public void promote( EmployeeLevel newLevel ) {
if ( hasBeenPromotedThisYear( this ) {
throw new InvalidPromotionException
好吧,在我正在使用此业务规则的应用程序中,将外部化为规则引擎.在DDD之后,我可以做类似的事情：
if( promotionRules.isEligibleForPromotion(this)
外化我的规则.但是,该系统比这更通用. “促销”操作本身通过外部配置定义为“过程”.因此,在编译时,我甚至不知道我是否为该员工提供了“推广”操作.因此,从代码角度来看,我的员工对象变得非常简单,将所有功能委派给配置.它可能看起来像：
public class Employee {
public void execute( Process process )
或者
public class EmployeeProcess {
public void process( Employee employee )
我的问题是：DDD在这个应用程序中是否有意义？我是否应该只在非DDD意义上模拟流程,验证,业务规则(规则引擎)的协作？
我喜欢洋葱架构,可以使用UI – >应用服务 – >核心 – >基础设施保持良好的关注点分离.但核心可能是上面提到的合作者,而不是真正的“领域概念”.
我的一部分认为,在这种情况下,“域概念”是验证者,处理者,业务规则,因为它们构成了我们在讨论系统时所讨论的无处不在的语言.在这种情况下,我会让实体没有真正的行为(大部分),以及处理器,验证器,规则引擎方面的域概念,它们实现了系统中的行为.
添加更多信息.鉴于我上面的问题,我正在努力寻找一个看起来像这样的解决方案：
org.example.app
org.example.domain
– 员工
– 公司
– EmployeeLevel
org.example.domain.shared
– 过程
– BusinessRule
– 验证器
org.example.infrastructure
希望这个小片段增加一点清晰度.
因此,Process,BusinessRule和Validator概念将位于域内,但会根据系统所做的事情支持域模型.
Domain-driven design (DDD) is an approach to developing software for
complex needs by deeply connecting the implementation to an evolving
model of the core business concepts.
我认为验证者,流程,规则不是您的核心业务概念.这些是相当常见的软件抽象.
我不是“by-the-book”DDD的忠实粉丝,但为了更加“领域驱动”你的DSL,你的规则实际上应该建立在你的业务概念之上,以便更好地理解它.
在引擎盖下,您仍然可以使用验证器,管理器,执行器等,但如果您使用其中的业务概念而不是软件抽象,则您的DSL /规则将更具可读性.
更新：由于您使用Groovy来定义DSL,因此您可以使用Groovy的动态方法名称解析和构建器功能来创建可读的规则和类.您还可以利用“约定优于配置”原则来勾选某些逻辑.例如,在Groovy中,您可以尝试构造类似于：
if (employee is "promotable") {
start "promotion" for employee
}
将是一个基础域对象的方法,它将检查是否存在让我们说EmployeePromotableValidator类,它本身也可以是一个利用Groovy的DSL表现力的Groovy类.
class EmployeePromotableValidator extends Validator<Employee> {
boolean validate(Employee employee) {
employee.age > 25 && employee.workingYears > 2
}
}
start将是您的基本规则脚本上的一个方法,它将搜索EmployeePromotionProcess类,该类也可以是Groovy类.
在这种情况下,规范模式非常简单,因为它基本上成为语言的一部分：
if (employee is "promotable" &&
employee is "advanced" &&
employee.salary < 10000) {
start( "salary increase","10%" ) for employee
}
通常,借助Groovy / Scala等(半)函数语言的DSL可用于隐藏软件抽象,并使您的业务逻辑在代码中更加突出.使用普通Java,你最终会得到很多锅炉板代码,最终会隐藏你的所有意图.
