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