Say I have a bounded context called: 'Loans' and the following APIs:


The three banks above are consumers and have an API. I am using the scatter gather pattern (https://www.enterpriseintegrationpatterns.com/patterns/messaging/BroadcastAggregate.html).

Would I have one domain model (.NET Project) for all three consumers or one domain model per consumer (.NET Project)? I believe I should have one domain model per consumer as the domain logic is only relevant to that consumer.

This is more of a though experiment rather than a real business problem. However, we will have to do something similar with the scatter gather pattern at some point so hence the question.

I realise both approaches I have described will work. I am talking more from the perspective pf the principle of least astonishment.

  • I Image you would have one domain model for whatever business logic you are conducting. Then there would be several plugins that provide implementations to this model, providing the access to the API's of various external entities in order to carry out that logic. Each Plugin is permitted to have its own internal domain with the express business logic of orchestrating that API.
    – Kain0_0
    Jun 6, 2019 at 2:18
  • The question is not clear to me. Are you writing an application/service that calls three different banks' APIs? Or are you writing an API that must expose the same data to three banks, all of whom wish to retrieve the data using a different API?
    – John Wu
    Jul 9, 2019 at 0:59

2 Answers 2


I would think you'd have one common domain model and then one domain model for each individual.

The common model's job is in offering services to consuming clients who don't care about the differences in API of the specific data source.

An individual domain model's job is in mapping custom API's into the common model.


It's contextual.

This depends on more than you've mentioned in the answer. At a very basic level, when you maximize reusability, you unite repeated logic and put it in a single location.

                         |               |
                    +----+ Loans.HSBC    |
                    |    |               |
                    |    +---------------+
 +--------------+   |    +---------------+
 |              |<--+    |               |
 |  Loans.Core  +<-------+ Loans.NatWest |
 |              |<--+    |               |
 +--------------+   |    +---------------+
                    |    +---------------+
                    |    |               |
                    +----+ Loans.TSB     |
                         |               |

Where you put a particular piece logic is a matter of whether this piece is reusable (= Loans.Core) or specific to a customer (= Loans.[Customer]).
The above example most commonly applies to class libraries, but it applies to domains just as well. Any sufficiently big or complex domain can warrant subdivision or abstraction.

For example, suppose all three banks do housing loans and personal loans, but NatWest also has "NatWest Premium" loans. Then it would make sense to have a core domain, with housing and personal loans, but to then also make a secondary NatWest domain which extends the core domain by adding "NatWest Premium" loans.

There is an argument to be made for adding "NatWest Premium" loans to the core domain and simply not using it in the other consumers, and that's certainly possible, but this can become an issue in cases where this leads to conflicts.
My given example is simple, but the difference between customers can just as well become a minute-yet-important difference in a class structure which is otherwise fully reusable. When you try to jam both versions into the same domain, you start running into if CompanyA then ... else ... logic which is incredibly prone to OCP violations.

Can it be done? Sure. But it requires attention to not slip into bad practice. If you separate the domains from the get go, it will be easier down the line to not slip up and muddy the separation of core and custom logic.

This is a matter of personal approach and how your team works. In my experience, I often work with junior colleagues who tend to slip into bad practice more often than senior developers would. Because of that, I tend to favor making it difficult to stray from the path, which deincentivizes people from taking a shortcut and devolving the code quality.
However, if you are confident that all developers will take personal responsibility in keeping things SOLID and good-practice-friendly, then you don't need to defend against the slippery slope of bad practice as much.


As a sidenote, a coworker of mine often proposes that when you make one custom domain (which extends the core domain), then you should make a custom domain for each customer (even if it just extends the core domain and adds nothing else).

I find that an arguable point. There's nothing wrong with it, but I don't quite see the necessity of it either. I think this is a matter of personal style and what you find the cleanest approach. It doesn't matter on a technical level.

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.