domain driven design - Drools vs DDD: Does Drools require Flat Object Models? -

domain driven design - Drools vs DDD: Does Drools require Flat Object Models? -

in our e-commerce domain, have hierarchy of entities modeled using nested arrays. using principles of domain-driven design (as explained eric evans). central concepts in our e-commerce domain are:

contracts, have exchanges, each of has both services , payments. services, in turn, have features describe each service.

this hierarchical model enables express contract, no matter how complex, including have multiple agreements (that is, exchanges) part of overall understanding (or, contract).

does drools not back upwards such hierarchical object models? should invert object model flat object model no arrays (like "fires have rooms" & "sprinklers have rooms" example in drools expert documentation) follows?

contracts. exchanges, each of has single contract. services , payments, each of has single exchange. features, each of has single service.

am right inverting hierarchical object models in way, flat object models atomic assertions, supported , works best in drools? drools doesn't appear back upwards rule lhs conditions on fact , fact in subcollection.

if so, why doesn't drools back upwards more hierarchical object models? because drools comes ai world (not object-oriented world) in first-order logic expresses facts atomic subject-predicate-value statements, , not object-oriented world in entity objects have identity, value objects don't have identity, , entity objects composed of other entity , value objects?

you can define rules against java object model.

the documentation provides examples based on toy problems avoid distraction it's explaining. not because drools incapable of dealing more complex models. if read bit farther through manual, see examples dealing lists using syntax such 'contains' or accumulators.

it's how model this. can insert contracts, exchanges, services, payments , features separate facts, reference each other. alternatively, insert complex contract fact, contains lists of exchanges, contain lists of services, etc.

which works improve depends on whether rules match on contract little chaining, or whether want rule react such alter in feature, or insertion of payment fact.

domain-driven-design drools object-model