CODEWITHSUNDEEP
c#.netdesign-patternsarchitecturedomain-driven-design
Naor
Naor

Reputation: 24093

single modular component should work with other components (component=module)

I have a question but I am not sure how to describe it properly so please read carefuly. First, lets define the term module in my eyes: module = bunch of classes, interfaces enums (and so on) intended for solving single problem. For example:

Today our application have bookkeepping module that intended to hanlde the whole bokkeepping need in the application.
We also have ModuleA that produces items that should be later used in the bookkeepping module in order to create invoices from them.
So, in order to let those two modules contact between each other - we actually didn't consider the both modules as modules and each module knows classes from the other module.
For example:

As you can see there is a real bond betwen those two wannabe "modules".

Now we got another need.
We also have moduleB and we need to use moduleB also with the bookkeeping. But, as I described earlier, bookeeping only knows items from moduleA and know how to interact with them and only with them.

How can we make the bookkeeping module generic/modularic enough so that we can use other modules also with it? Lets assume I manage to separate somehow moduleA, moduleB and bookkeeping, and lets assume bookkeeping doesn't know the other modules. There must be someone who knows all the modules in order to connect between them! Who will connect between moduleB and the bookkeeping?

I really appriciate possible architecture solutions, diagrams and links to relevant information I should know.

Thank you very much, Naor

Upvotes: 2

Views: 151

Answers (1)

eulerfx
eulerfx

Reputation: 37739

If I am understanding the question correctly then I believe the issue you are running into relates to the DDD concept of bounded contexts. It seems that you have a bookkeeping context and another context which may trigger bookkeeping events. The DDD way of solving this problem is to create a different model for each context. For example, suppose that Module A is a products context, it contains the domain model for products for sale. Within this context there are many aspects related to products, product descriptions, pricing, etc. Specifically, products in this context are entities. From the perspective of the bookkeeping context, the notion of product manifests itself as an invoice line item. The only aspects of a product that are important to the bookkeeping context are the product ID and the price at the time of invoicing. Products are likely not entities in this context by value objects. Since the notion of a product is different for each context, a different model should be created. The only thing shared is the product ID so that it can be known which product is being referred to by the bookkeeping context.

Factoring the system in this way solves many other problems which arise when disparate contexts are cramped into the same model.

Upvotes: 1

Related Questions