Bounded Contexts and Subdomains exist at different levels.
A Subdomain is a portion of the problem space, it's a natural partitioning of the system, often reflecting the structure of the organisation. So logistics and operations might be separated from invoicing & billing. Eric differentiates core, supporting and generic subdomains according to their business relevance in the given scenario.
Contexts are portions of the solutions space. They're models. It would be a good thing to have them, reflect the domains-subdomains partitioning ...but life isn't always that easy. And you might have bloated legacy domain encompassing everything, or more context in the same subdomain (i.e. old legacy app the replacement app somebody is building).
To have a Bounded Context you need to have a model, and an explicit boundary around it. Exactly what's missing in many data-driven application that use databases to share data.
Another - orthogonal - way to see it may be the following. Ubiquitous Language, the special condition where every term has a single unambiguous definition, doesn't scale. The more you enlarge it, the more ambiguity creeps in. If you want to achieve precise, unambiguous models, you need to make their boundaries explicit, and speak many little Ubiquitous Languages, each one within a single Bounded Context, with a well defined purpose.
A little remark, and then a tentative answer.
Use eventual consistency between aggregate's boundaries (before asking whose job it is)
That's aggregate design by definition. We might argue whether this is a good or bad decision, but the Aggregate in Domain-Driven Design is a "unit of consistency". This is not to say that this is "the right way to do things", only that, when we talk about aggregates, this principle is somewhat implicit.
If I'm not mistaken, one of DDD's reasons for being is avoiding spaghetti code, where business logic is scattered all around on, most of times, a fat service layer. Are you not scattering business logic when you use eventual consistency?
DDD doesn't exist for avoiding spaghetti code, but to provide a sensible way of designing code in places where you have frequent evolutions (due to intrinsic domain complexity - code is changed because people learn - or to rapidly evolving domains - code is changed because we are competing with new ideas). However... spaghetti gets in the way when you are pushing for frequent changes. ;-)
"Scattering business logic" per se isn't a good or a bad thing, until you take into account Bounded Contexts and different purposes that the software might serve. If the business logic belongs to different bounded contexts, then it's fine if it's not in the same place. In CQRS/ES for example, coordination logic frequently gets placed into ProcessManagers, reacting to external Domain Events.
Is there any other way to represent the business ubiquitous language other than having a rich domain model? Can't the language be expressed in a fatter service layer?
Another little clarification is needed: there is no such thing as "the business ubiquitous language". There are many languages with different purposes. They can be made ubiquitous and consistent only within the boundary of a Bounded Context, where they will be expressed well... everywhere (that's the ubiquity), from Acceptance Tests to UI labels to database field names.
The need of a fatter service layer often arises from a misconception of what a model is. If the model is principally behavioural, then its behaviour is decoupled from what users need to see. However, this decoupling is not spread evenly: some portions of the system will look CRUD-like, while in other portions the distance between what the software is doing and what a user needs to see might be strong enough to call for distinct models.
Focusing on what users need to see leads invariably to overlapping models: things with the same name that different users use in different ways. That's because the data looks the same, forcing promiscuous sharing. When the data is promiscuous, the obvious place to put the logic is the service layer. But the problem is upstream of that.
Best Answer
For a number of reasons, the literature is pretty weak here; but I believe that you will find that the taxonomy of "domain events" and "integration events" is more popular than the spelling you are using.
Pretty much. Many of the earlier uses of domain events had handlers that ran in the same transaction as the triggering "aggregate".
That distinction is important for your other questions -- because the handlers were running in the same transaction, all of the updates would fail or succeed together. That eliminated consistency concerns.
No; having an event store won't solve this problem. The main consistency issue that you face is a consequence of the fact that you aren't saving the domain events in the transaction with the aggregate.
If you have the domain events in place, and appropriate plumbing to retry delivery of those events after a restart, then your system can eventually recover itself into a consistent state.
See, for instance, Udi Dahan: Reliable Messaging without Distributed Transactions.