3

I have an ERP project with multiple sub-domains. It is not using CQRS or domain events.

I have two sub-domains; CRM and Accounting. The customer concept needs to be modeled differently in the two sub-domains. CRM needs to know the size (number of employees) of the company but not the tax number. Accounting needs to know the tax number but not the size. The company name is needed by both sub-domains.

I am thinking of modeling both CRM Customer and Accounting Customer as entities. But then whenever a new customer is created by a CRM user, an Accounting Customer instance also needs to be created. And if a report needs information from both sub-domains, then the queries become more complicated then when you have single entity containing all the information.

Is this the way to go? Is there a better way? Does it make sense to have multiple sub-domains without utilizing domain events?

aycanadal
  • 1,106
  • 2
  • 15
  • 42
  • Seems right from a ubiquitous language perspective. A CRM Customer and an Accouting Customer are obviously not the same. Whether this will hold together without CQRS or applicative separation between the two BC's depends entirely on your context - number of users, size of development team(s), deployability needs, etc. – guillaume31 Nov 09 '17 at 10:52
  • Domain events are just more practical from a maintenance perspective (inversed dependency, adding subscribers is easier), they open the door to asynchronicity and allow to better express what happens over time, to communicate better inside the dev team and with domain experts. – guillaume31 Nov 09 '17 at 10:57
  • Are you sure you've identified you bounded context boundaries correctly? Take a look at https://medium.com/@wrong.about/ddd-strategic-patterns-how-to-define-bounded-contexts-2dc70927976e – Vadim Samokhin Dec 01 '17 at 06:43

1 Answers1

4

Are you sure you need DDD? The use case seems quite simple, maybe you just left out all the other complexities, but from just the info you're asking, a simple CRUD app would do. Data Centric apps, like reporting, don't need DDD. You need DDD when you must modify the data in strict ways, to maintain consistency.

If you are sure you do need DDD, then you need to understand the point of the model is to protect against the invariants of the domain. You say a CRM Customer must always have an equivalent Accounting Customer. How is this handled by the business today? How does accounting know about CRM customers? How does accounting know they're talking about the same customer as CRM? However they are doing it currently, is what you should try to model.

As an example, if they do it in real life by just letting the other one know. You could have your CRM context publish a new Customer event, and your Accounting context could react to it by creating an Accounting Customer for it.

If on the other hand, they both learn about it from something else, then maybe they both react to that other something's event.

If you don't want to use events, it could be a direct call, from the CRM context to the Accounting context. Though know that this would grow more restricted as the app grows, but if again you've got a simple domain, its no problem.

Also, querying data is not the same as modifying it. Queries should not use the domain model entities and value objects. It could, but it should not be constrained by it. That's because query is a read only operation. You need to put your data inside your domain model only when you are going to change it.

Didier A.
  • 4,609
  • 2
  • 43
  • 45
  • 1
    Actual domain is bigger. Just gave an example of a case because in most of the discussions about concepts that are used across domains, one domain has all the information in an entity and other domains just make copies of part of that entity into a value object. I was just wondering what if two domains need completely different information about the same thing. Where do you keep it, how do you sync it. Looking at the real life part is what I was missing. This always looked like a technical problem to me. – aycanadal Nov 09 '17 at 08:11