We have this DDD project where we have more then one BC, and we have this scenario where we would like to define a proper way to store account settings.
In scenario A, we would have one BC store settings for all BCs, and have it published to each BC accordingly, and in Scenario B, each BC holds its own settings, and in Scenario C only one BC stores all the settings.
Scenario A is good to maintain business logic all at one place, it keeps BCs decoupled, but there is this overhead of maintaining publishing/subscription for each BC. Scenario B on the other hand has less overhead, but in case any of BCs has a need to use settings from different BC (business logic can always change), BCs are again tightly coupled. Scenario C provides least overhead, but no autonomicity.
Does selection of scenario solely depend on business needs, or are there some patterns of DDD that we should follow here?