If we take the example of a fictional company called BuyIt, which deals with an e-commerce Domain, it may make sense to create a different application for each of the different Bounded Contexts solving specific Domain areas.
If some of the different Bounded Contexts are Order Management, Payment Management, Catalog Management, and Inventory Management, we recommend having an application for each one:
Each application exposes any set of delivery mechanisms needed. With the microservices trend, more and more people build Bounded Contexts that end up exposing REST APIs to the outside world. However, a Bounded Context is more than just an API. Remember that an API is just one of many delivery mechanisms; a Bounded Context can provide a web interface to interact with too.
The best option is one Subdomain, one Bounded Context, and one application. If we have a Bounded Context implemented with two applications, the maintenance and the deployment get a bit tricky. And in the case of an application implementing two Bounded Contexts, the deployment process, the time for running the tests, and merging issues can slow down the development.
Beware that each Bounded Context name represents a meaningful concept in our e-commerce Domain and is named in terms of the Ubiquitous Language:
- Catalog to hold all the code related to the product descriptions, product combinations, and so on.
- Inventory to hold all the code related to the management of product stocks.
- Orders to hold all the code related to the order processing systems. It will contain the finite-state machine in charge of processing orders.
- Payments to hold all the code related to payments, bills, and waybills.