Should one or a separate database be installed for each limited context for each database?

Question

In DDD, as I understand it, it helps or guides you on how to structure a complex application. Now in the application you must define your limited context. Say you have more than 10 BC.

I read somewhere (sorry, I can’t give any links) that its not ideal to have a 1-large database for a complex application. So that it is separate for each aircraft. If it will be an easier way. How to create an application structure if each BC has its own database.

I tried to search on github but cannot find it.

Answer 1

It depends on whether they have only one and the same database, as well as some tables - i.e. data.

Sharing a database, but not tables, can be wonderful. Also, if you are focused on scalability and intend to make your BCs independent deployable and executable modules such as microservices, then they probably should have their own instance of the data warehouse.

I see several more flaws in database tables shared by two or more Restricted Contexts:

• Tight coupling. The reason we have a distinct BC is because they represent different domain spaces that can diverge in their own way. Changing the concept in one of the BCs can affect the base table, forcing another BC that also uses this table to change. You get rigidity where flexibility should be. You may also have inconsistencies or holes in the data due to the many possible sources of change.

• Concurrency. In highly competitive systems, some entities and the tables below them are subject to strong debate. Limited contexts are one way to facilitate loading by separating different types of records, but this only works if they do not block the same data at the end of the day. The same is true for reading on systems other than CQRS, where they query the same database where the writes are made.

• Friendliness ORM. Most ORMs will not allow you to display 2 or more classes from the same database table without a lot of convolutions and workarounds.

How to create an application structure if each BC has its own database.

To some extent (for example, which may include a user interface layer or not), just as if you had several separate applications. Please be more specific if you have clear questions.

Answer 2

The idea of ​​having this vertical slice for a limited context is the relation of each BC to each other aircraft, and the relationship between them should be considered and developed based on domain knowledge, and not on the technical advantages of persistence technology.

If you have a Client in two different BC, it causes a certain acting picture. If Support BC needs to know about a new Client when it is created in BC BC Sales, then Sales BC must connect to the known interface in Support BC and transfer this new information to it. One domain is talking to another. He quite accurately describes how everything works in real life, when people from different departments talk to each other.

If you are sharing a large database (here you are talking about corporate software, so there will not be many examples in the wild), then the temptation is to go around all the domain expertise that is captured in domains and meddle in another BC database. Things become a big ball of dirt very quickly.

Surprisingly, I see such things too often in the real world, and I find this a very bad practice.

Answer 3

It depends on why they are their own database. The idea of ​​a limited context is that you have a set of entities that are related to each other and solve a problem together. if you look at the Chaim Eliyah link provided that you may have sales and a support context. http://martinfowler.com/bliki/BoundedContext.html

Now there is no reason for the product to be sold, and the product for support should look the same in the database. The important thing is that if support wants to add a property (say, "low quality"), that he can do it, while sales may not want this property. Also, the downtime of your trading application will probably not affect your support application.

These objects do not care about where they are stored. If you already have a huge product database, you can, of course, create your own entities for different limited contexts based on the same database. It should be remembered that the database table does not match the entity. Objects are what your business / application needs. A database is what you need to store things.

However, separately, if possible. If this is not possible, try to identify the owners. You make your life a lot easier if everyone agrees that the product is a sales-specific product, and this support may have a “productfactsheetTable” that complements the product. This way you avoid conflicting changes in every limited context. (It also follows that support can only read products, but never write). Table prefixes can help here make this clear.

And this problem already exists with 2 related limited context. By 10, you will have a nightmare if several contexts try to write to the same table.