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
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)?