2

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?

enter image description here

2

Your analysis is pretty good, and all 3 options seem valid, although they have different characteristics. Now you need to evaluate which design makes sense for your specific situation.

Consider whether it is disastrous for Order management and Pricing management to have not yet received the latest settings. If so, then scenario A is not good.

Consider whether you want users to be able to view and edit all their settings even if Order management or Pricing management is experiencing errors. If so, then scenario B is not good.

Consider whether Order management and Pricing management need to be able to read settings even if Account management is experiencing errors. If so, then scenario C is not good.

1
  • 1
    i upvoted your answer, but it really does not providing any value. it just further elaborates on this diagram
    – John
    Nov 22 '16 at 14:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.