1

Say that we are developing an application with modules (Sales, Accounting, Purchasing, etc).

An example case here is :

Sales module is the basic / primary module available, and Accounting module is a complementary module.

SalesModule
-. Product

And

AccountingModule
-. Account
-. Journal

If we were to say that :

If the Accounting Module were installed, then it will provide a direct integration with the Product class from the Sales Module, such as : a Product now has a List of Account which if a transaction is applied to the Product, a Journal will be posted according to the Account.

In my mind, I would picture that Product would have a property of List<Account>, but that would be impossible without adding that property directly in the Product class, making Product now dependent on Accounting Module when SalesModule should be able to run without it.

Another solution came up to mind is to add SalesIntegrations classes (ProductAccount, etc) to complement the previously described Product, making it independent. But this solution doesn't sound as 'natural' as saying that a Product has a list of Accounts.

From what I understand, doing DDD means to know beforehand the whole concept of business rules.

What if a requirement come along to add a new project to complement the previous DDD project with only having it's DLL (no access to source code)?

2 Answers 2

1

In Eric Evans book the problem you are experiencing is somewhat touched when dealing with Bounded Contexts, which are contexts that are born separated (legacy, different teams, etc.) and need to interact.

It all depends on the investment and resources, but if as you said you only have access to the DLLs, you cannot use any approach that involves refactoring commonalities out of the other module, so you will have to live with it in a fashion similar to dealing with legacy code.

The approaches you have are described in the Context Mapping strategies. In my opinion, given the inability to work on the existing code, a defensive approach like an "Anti-Corruption layer" could be the case.

-2

Many MVC frameworks make use of Inversion of Control to inject dependencies and make them more flexible. Not sure how tight your integration should be, and even further how decoupled these modules should work. eg. are they all standalone applications?

You may want to have at look at some patterns that inject dependencies, it's a way of having loosely coupled modules. You can also create interfaces to formalize and create 'contracts' among modules. eg. AccountAwareInterface, with something like setListAccount and getListAccount.

If the Product module should work irrespective of other modules, I would extend affected Product classes and integrate there. But how you make use of one or other class, certainly it has to be configured properly.

Not sure if it helps a bit.

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.