If you have two Bounded Contexts where one depends on the other but not the other way around, then you usually have a customer-supplier relationship between the two. There will be consensus on the agreed upon interface via which the customer can access the supplier, and the supplier agrees to serve that interface and respect it. Changes to it must be discussed with the customer.

A natural extension to this is an Open Host Service. If the supplier has many customers, it will be too cumbersome to discuss and implement interfaces whith each customer individually. Instead, the supplier decides to define one interface all those customers can access. The difference to Conformist is that a Open Host Service does care about its customers and defines and respects the services it puts in place. With conformist, the leading context is free to change things in any way it desires.

This is open for grabs. There is not one defined protocoll for suppliers and customers to communicate. Depending on the circumstances, you may integrate via

• published database views of the supplier¹⁾,²⁾
• published services by the supplier ³⁾ the customer can use⁴⁾
• published events of the supplier the customer may consume⁵⁾

This is probably one of the most primitive ways of integrating contexts, but also one of the easiest if the team is small and the contexts share a database or database server. The contract contains the following

• Database⁶⁾
• Connection Information⁷⁾
• Authentication Information⁸⁾
• View names
• Field names and Types
• Description of the views and fields
• Invariants maintained for the data

Anyone interested can acces the views, either by polling data from them regularly, integrating the view data directly in their own read models⁹⁾ or any other imaginable way.

The advantage of this type of integration is fast and seemles immediate consistency. If you need the suppliers data to incorporate information in the read model inside your own domain, you can do so directly by joining your own tables and views with the suppliers views. No need to poll the data first or cache it yourself.

The disadvantage of direct integration of the suppliers views in the customers read model is that the customers services depend on the availability of the suppliers services. Another disadvantage is that direct integration is only possible if the suppliers and customers views share the same node. If not, some sort of replication is required.

If the supplier data is sharded, and there is no one-to-one sharding between customer and supplier, direct integration via replication and synchronization schemes probably doesn't make much sense. There was a reason for sharding, and replicating the supplier data from all nodes to each of the customers nodes would make the original decision obsolete to some degree.

In a situation like this the customer will probably poll the supplier, placing its own services on each of the suppliers nodes which can satisfy the requests by going tho the published views. The customer can poll regularly and cache data¹⁰⁾, or poll on demand.

Simple applications with no necessity to shard and which share one database server can benefit from the simplicity of this type of integration. More complex architecture requires more complex solutions, of course.

Actually, this type of integration is conceptually exactly the same as polling via a query service. You poll the suppliers tables and views for data. Only that you can optimize polling for lists by being allowed to join directly, i.e. you use the database engine to optimize the querying of the supplier. In both cases the data you are obtaining from the supplier is quite current¹¹⁾, and you always have the additional possibility of caching polled data.

As always, it depends. If you can always rely on the possibility of integrating via the database, go for it. Actually, if it is a possibility in the current situation, go for it. If things change, move to a different polling solution or maybe even to a push solution. But if there is no need for a more complicated and less consistent solution, you should not make that move right away.

The implementation of the read model will have a dependency on the available integration technologies with supplier contexts- that's a real drawback. A simple salvation is to wrap the customers read model with an abstract view representation. That view can then be built either by direct database integration, by pulling date from the supplier or by having data pushed from the supplier:

If you now choose to directly integrate through the database, changing that decision later will only result in you having to change the way the abstract view is fed. If you move from direct database integration to a push or pull solution, you will also move to an eventually consistent representation of the suppliers part of the data of the read model. That may or may not be something to consider. If it is, you can add information to the read model. You could

• Have time-stamps per read model to represent how recent the data is. That information can either be displayed to the user in the UI, and/or application services using that read model may have contracts stopping them from using data that is too old,
• Invalidate the read model if you have not received data within some defined time-span. If the UI or an application service tries to access that data, an exception will indicate that the supplied data is out of date.

In either case, the read model itself can use the abstract view and not care about the up-to-dateness of the data. Additional mechanisms will be put in place if stale supplier data becomes an issue.