From: Sean DeNigris on 19 Feb 2010 15:22 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? Sean |