From: Sean DeNigris on
It seems like everyone's saying the same thing, just not agreeing on
the vocabulary.

When I think about accounts, of course, not being in the financial
industry, I think of withdrawals, AMTs, balances, etc. And if we were
implementing a system just to cater to stakeholders like me, account
may very well be a domain object.

Now, consider the above as one view into the data of an entire bank.
This is one specific high-level view of the data. It builds upon a
lower-level view of transaction logs which is necessary to support
other stakeholders - say auditors.

Because we are separating the concrete objects from their roles in the
different contexts, in the 1st context - yes, I'm going to call it an
Account, and as far as I'm concerned, that's exactly what it is; it
appears to be an object that "has" a balance, etc.

However, when I link up actual objects into my context, I won't find
an Account Object. At some point, someone will have to build code on
top of the transaction log code, to give me the interface I need. In
DCI, it seems this would be a CustomerAccountContext, or
AdjustAccountBalanceContext, or something similar.

A great term that I've heard JOC and Dan North (who invented BDD -
amazing and relevant stuff that will help you understanding this) use
is "Turtles all the way down." You implement one layer or view using
words that make sense at that level, and then the next layer down, you
use totally different vocabulary to describe the same objects/
behaviors with that layer's terminology, and so on... In DCI, it
seems that what you hit are the underlying domain objects - the lowest
common denominator objects that are at the core of the entire system.

Does that make sense?