In application development, DDD defines problems as domains and subdomains. Independent steps and problem areas are then defined as bounded contexts. A common language is encouraged with definitions for entities, value objects and aggregate route rules.
Sokhan says it is very similar to microservices: the goal is to separate monolithic applications into multiple, stand alone service applications. For those not wrestling with the technical debt of a legacy system, services can be created from the start using bounded contexts.
In monolithic, legacy systems, it is not uncommon to have integration of various services occur through the database.
But as more enterprises seek an agile way to develop new customer-facing products and to scale existing initiatives, architecture that integrates services via databases prevent horizontal scaling (because they need to add more application servers to grow) and end up needing to blur business logic by including it in some database models.