Question

DDD关于多功能参考资料设计的建议是什么?

我是否试图将它们作为“Matryoshka”(向另一个国家投入)或更好地建立“中间”商务服务?

P.S. 跨越这一平水,我找不到任何东西可以在因特网上读到,并且开始认为,就这种事情而言,比“相互参照”更合适。什么时候?

DETAILS:

I have two models/business services.
Semantically first domain (A) is CRM with sell/maintenance process for our goods, second domain (B) is "design" data of our goods. We have two view points on our goods: from seller perspective and from engineer perspective.
Actually each model is effective ORM (Object-Relational Mapping) tool to the same database.
There are some inter-domain activities e.g. validations (e.g. sometimes we can sell things to smb. only if some engineering rules are valid).

从开发商的观点看,我有两种明确的可能性(A中的参考B或创建新的交叉参照领域/服务C)。但从设计者角度看,我对我从两个不同领域形成业务逻辑时拥有何种商业服务失去了理解。

Answer 1

As far as I know, DDD has no strict rules for inter-domain referencing. At the end of the day your domain model will have to reference basic Java or .NET classes. Or it may reference specialized date/time or graph library (aka Generic Domain ).

On the other hand DDD has a concept of Bounded Context. And it has quite a few patterns that can be applied when you work at the boundaries of the system. For example Anticorruption Layer can be used to isolate you from legacy system. Other integration styles can be used depending on how much control you have over external code, team capabilities etc.

因此,如果你只是在一个博迪德的环境下处理两个子域,则可能没有必要引入人工冰川层。也可阅读DDDbook(战略设计)。

最新资料:

Based on the information you provided, it looks like you only have one Bounded Context. You don t seem to have linguistic clashes where the same word have two different meanings. Bounded Context integration patterns are most likely not applicable to your situation. Your Sales domain can reference Products domain directly. If you think of Products domain being more low-level and Sales being high level you can use Dependency Inversion Principle. Define an interface like ProductCompatiblityValidator in Sales and implement it in Products domain. And then inject the actual implementation at the application layer. This way you will not have a direct reference from Sales to Products.

Answer 2

Dmitry已经说过......

我认为,任何跨越受约束背景的法典,作为应用层代码。我从两种情况(及其存放处)来看,应用层代码参照领域类型,但彼此之间没有两个参照领域。我认为,如果应用层面的具体跨越领域界限,并且可以进行单位测试,那么在应用层中具有商业逻辑,那是科索沃的。

If you really have a hierarchy, then it would be OK to have the the more concrete subdomain reference the more abstract domain. However, I would be careful if this causes you to need to have domain objects reference repositories of any type. Pulling objects out of of a repository is rarely a true domain concept. Referencing repositories is best done in an application layer that sits a layer above the domain model.

Of course this is all as much art as science. I d try modeling a thin slice of your application a couple different ways and see what friction you run into with each approach.

友情链接