2

I'm midway through Eric Evans' DDD book but don't think this question would be answered in the book.

If an application has its own complicated concepts different from the underlying domain, can we create another domain model for representing the application too?

An example would make it clear. Say, the core domain of an organization is Information Rights Management, that is encryption of information and control of its usage according to access rights of users. One of their applications is an IRM enabled e-mail client like Outlook which encrypts outgoing e-mails using IRM. Now, an IRM enabled e-mail client is in itself a very complicated application and may have several new business rules regarding IRM in e-mail, entities, and operations. In such cases, is it wise to make another domain model to represent an E-Mail client only within the application and use both the core IRM domain model and the e-mail domain model together? Note that IRM in e-mail is not the core business of the organization but nonetheless they have an e-mail client that revolves around IRM.

Improve this question

1 Answer 1

Reset to default
1

Maybe the concept of bounded contexts (https://martinfowler.com/bliki/BoundedContext.html) is the right one here.

If the usage and meaning of some concepts differs very much in different contexts (may a email in your case), you can introduce a boundary and translate to and from both contexts.

Otherwise, why split the model up into two, the core domain is already separated out as you say.

Improve this answer
7
  • I had thought of Bounded Contexts. I'm not sure it applies to unrelated concepts like domain and application. From what I read, it applies when different teams have different languages for the same concept. Maybe somebody can confirm here.
    – Kapil Dhaimade
    Apr 25, 2018 at 6:03
  • @KapilDhaimade it's something like that, but more like "different concepts for the same words".
    – guillaume31
    Jul 18, 2018 at 7:22
  • It's unclear to me why you emphasize domain vs application. Just because IRM is more action-oriented (encrypting) and less data-oriented in nature doesn't mean it is restricted to the application layer and can't be a Bounded Context of its own.
    – guillaume31
    Jul 18, 2018 at 7:23
  • @Kapil You would make a 2nd .cs file and call it someemailclientcontext.cs, which talks to IRM client directly. You would then translate that into your domain model. In Eric's book, he has a chapter on anti-corruption layer, you can use that or if the IRM implementation is heavy, make a stand alone project for it.
    – RandomUs1r
    Nov 13, 2018 at 23:26
  • @RandomUs1r, That would imply that we're using different Bounded Contexts right? I just want to confirm that we can use a Bounded Context for an Application layer concern. In this case, the Mail Client is just 1 Application and not a core domain of the IRM company. Should we still treat it as a Bounded Context or there's some other pattern for complex Application layer entities?
    – Kapil Dhaimade
    Mar 19, 2019 at 14:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.