"Code must be Chunkable"

[James Coplien]

Hi James,

Honestly, James, I didn't even think about contacting you --I didn't
even suspect I'd be getting this deep into a conversation about it.

The I'm happy to offer a revelation in your mindset. And welcome to the
Internet world.

However, while your example gave me at
least something to go on, the presentation as a whole left me more
confused and thus less enthusiastic about the whole DCI idea.

That is in fact probably good! That is what should be happening as you
make a paradigm shift. Expect to be confused and surprised.

I'll come back to this notion throughout the mail.

My example didn't only extemporize on Trygve's, but went into some new
territory. And I think some people got lost there.

I know this sounds like rationalization, but in fact, most of my
teaching the past thirty years has involved some kind of paradigm shift,
and I am attentive to the need of this puzzlement. If you read "Zen and
the art of motorcycle maintenance," Pirsig calls it "stuckness."
Learning new things is not always a linear process.

I apologize for compacting this opinion into the one word "awful", I
suppose that is too disparaging a term, and for that I apologize. So
please accept this explanation in it's place and take it for what it's
worth.

You can call me whatever you want to my face, and in this discussion, I
hope you do, you ignoramous I am more hurt by the fact that you
might have seized an opportunity for dialog and learning but instead
cast aspersions mumbling in a corner somewhere. I feel hurt on behalf of
the community. We need your criticism — but in dialog.

The definition seems fine. I just don't see why logging-in can't be
viewed as a goal in itself.

As most use case experts would describe it, you don't go home at the end
of the day and tell your daughter, "Guess what I did today! I got logged
in!" Logging in isn't essential to the value chain. The goals in
goal-driven use cases drive towards such goals. To focus on things at
this level is noise.

Alistair Cockburn's "Effective Use Cases" offers the theory and practice
of this perspective in a very satisfying way. Give it a read and come
back and we can discuss it more.

Ok. This is my take. DCI seems to me like an idea with a lot of
potential. But I don't think it's an all of nothing kind of thing.

No one is saying that it is! There is still a place for your
grandfather's object-oriented programming. There are architectures we
can call event-driven architectures, where the interesting operations
are all atomic. A shapes editor is a good example. It in fact has no use
cases. Most operations are atomic and trivial: "Change the color of this
shape." "Resize this shape." "Create this shape." Once in a great while
you might have operations involving multiple methods of multiple shapes,
and that's where DCI comes in.

More broadly, not everything is object-oriented, whether DCI or your
grandfather's object-oriented design. Procedural design still has a
place. So do state machines — and that has nothing to do with objects
(for example, in protocol design). So does rule-based computation. So
does functional programming as in SASL or KRC. Anyone who attacks the
world with one weapon alone will be defeated. I wrote a whole book on
this several years ago called "Multi-paradigm design.

Why did you think I felt that DCI was the only way?

get the feeling that you so badly want DCI to be a Major Paradigm
Shift that you might be pushing it's concepts too far.

Given that it took me seven years to learn it, I can speak strongly for
the fact that it is a paradigm shift. That it is a paradigm shift has
nothing to do with its payoff — only with the mode of understanding.

You may be seeing some of my pedagogical techniques that are commonly
used to extemporize new ideas. There are important ways of giving
emphasis in a one-hour presentation that would not arise if we were
pairing at a keyboard.

For instance, to say that an account is not a not object... going all
the way back to the bad old days of COBOL, an account has always been
treated as as object, even if not coded in OOP form.

I don't think so. Have you ever worked in finance or banking? I think
your statement holds true only in lectures by college professors or by
people outside of finance. In the latter case, the object isn't the
account, but the name of the account (sometimes called its account
number). Can you give me a single example in the software of a real
financial institution where the balance is actually stored as a data
member of an object in memory?

After you answer that, we can discuss the difference between
object-oriented programming and class-oriented programming. One of the
major features of DCI is that it supports object-oriented programming.
Very few languages support object-oriented programming directly: they
support class-oriented programming instead.

That's because
banks treat accounts as objects --people have them, they have ID
numbers, etc.

You are perhaps suffering from being trapped in the old paradigm, where
everything must be an object. Stick with me here for a few paragraphs as
I explore this. You would have been an excellent student of Kant. In
fact, if you look at people's mental models of their worlds, they think
of much more than objects. An ID number is not an object: it is a handle
to an object. An account is not an object: it is a role that several
objects together can play.

Do the following experiment. Go to someone who has recently done a money
transfer in their bank. Ask them to give you a general user story for
it. Inevitably, I find people saying, "I decide on an amount, and then I
witdraw that money from one account and put it into another account." If
they speak more precisely they will use terms like "source account" and
"destination account." A "source account" is not an object. It is a role
that something can play (like a savings account).

For the time being we can pretend that savings account is a class whose
objects can play the role of "source account." That fits the simple
Kantian model of the world, where most things must be objects. But if we
go more deeply, to the level of that domain (in the sense of DDD) we
find that it is not an object — certainly not in the "D" sense of "Data"
in DCI. It is a collection of use cases, of behaviors. That makes it a
DCI context. An account is a context (like an account number) in which
we can carry out algorithms (like transferring money) with other
concepts (like other accounts, or transaction logs, or audit trails).

Where I think you are confused is that you take these elements of your
mental model and call them objects. That was also what Kant does. To do
so is at least not useful, and probably isn't even right. Also part of
your mental model is the mapping from the roles "source account" and
"destination account" onto their respective accounts (my savings account
#O991540 and my investment account #393497654). Also part of your mental
model is those things called accounts, and you think of them as objects.
The problem is that the people who implement those systems don't
implement them as objects, but as something else — the objects are at a
much lower level. That's the real world of real financial software
today. Really. At least in my example — which I think is representative.
If you have a different example where an account can be an object in
memory, I find that interesting, but I don't think it's germane to this
discussion.

One reason I can justify DCI as a paradigm shift is that it differently
translates the mental models of end users and programmers into code.
Something called object-oriented programming was one way of doing it in
the 1980s. This is another way of doing it, with different elements of
the model. And these elements don't come out of thin air. Rebecca
Wirfs-Brock and Trygve were having a discussion on the Hurtigruten about
ten years ago as I was listening, and they concluded that objects don't
have responsibilities — roles do. That is the essence of CRC cards. Most
people think that CRC stands for "Class, Responsibility, and
Collaborator." It does not. Rebecca wanted to call them RRR cards
(Roles, Responsibilities and Relationships) but the C really stuck. What
it really means is "candidate object," and it's a role. (I just verified
this with her when she and I went together to dinner with Trygve and
Gertrud at Øredev last year.) So you have an entire industry focusing on
classes because they misunderstood an acronym (or popularizers of the
technique misunderstood it – I won't mention any names). Focus on roles
— the roles that objects can play — not classes.

There are other ideas I could bring to bear from the field of user
experience, from Brenda Laurel's writings, and from other staples of
object-orientation that the Java-duped public doesn't read, but take my
word for it. This is not the object-orientation you learned in college.

Then please make it available!

It's there (somewhere) on object-composition (are you subscribed?); it
appears in its entirety in the book I have coming out in June (there are
several drafts scattered here and there on the web).

Part of understanding a new paradigm is going beyond a one-hour talk to
do your homework. Read the Artima article. There are three or four
articles you should probably read at Trygve's web site. If you're really
interested, come to the next course I offer on it. Just for you, I'll
give you a free seat.

Please don't feel that I am criticizing *you* --take it for what it
is, my personal critique of *your presentation*.

Likewise, I am not criticising your understanding, but how you channeled
the criticism.

I can can certainly offer some suggestions, but I would have to
understand DCI better to go beyond the surface.

I suspected as much. My guess is that your sense of distaste in the code
may also owe to being stuck in the old paradigm.

The goal of AOP is to come at a problem orthogonal to the traditional
OOP direction. In AOP you are organizing code into aspects. These
aspects are like contexts in DCI. Aspects are composed of advice, code
injected into classes/objects by wrapping other methods.
There are clear similarities. DCI goes a bit further by injecting
methods whole-clothe, and in doing so decomposes "aspects" into a
context and set of roles. (Actually that might be useful, might DCI
roles make use of AOP's concept of advice too?)

No, because it makes the aspectualized code unreadable. As to why DCI is
more than AOP, read my above long segment on mental models and
paradigms. DCI is not just a programming trick to reflect cross-cutting.
It can represent much higher dimensions of cross-cutting than AOP can
and, because of the Contextual mapping of roles to objects, is much more
dynamic. They are barely in the same league. I think you are confusing
one of the mechanisms of Aspects with one common mechanism used to
implement DCI in some programming languages.

This, too, is the sign of a new paradigm: everyone tries to describe it
in terms of what they know. Some people say that DCI is like mixins.
Some say it is like multi-paradigm design. Some say it is like aspects,
some like dependency injection, and a million other things. What gives
me the most grief is that there is a tiny bit of truth in each of these
claims, just enough to keep people from making the necessary mental
leap. To do that requires digging into it and trying it. It is like
learning a martial art: no number of PowerPoint slides will get you
there. You have to feel it in your bones. Most people don't even "get"
object-oriented programming in their bones. And this transition scares
programmers because their identity is so tied up in understanding new
technology. That leads people to do really amusing things. For example,
someone may not yet understand DCI well enough even to give suggestions
on how to clean up Ruby code that illustrates it, yet feels qualified to
criticize one of its inventors as "not getting it." O, how human we can
be...

But back to the point... The real goal of AOP (I have this from Gregor
Kiczales personally) is to shock people into taking reflection
seriously. It was supposed to scare people from Java back into Lisp,
where you can express these things cleanly. Cutpoints and wrappers and
whoppers are native to CLOS, for example. The problem is that people
weren't shocked: they embraced the scaffolding. I view this as one of
the best examples of the sheep-like stupidity of the industry,
collectively.

I'm going to get back to my vacation and attacking the fjelds of Norway.

Med venlig Hilsen, Cope

 

[Marnen Laibow-Koser]

James Coplien wrote:
[...]

I don't think so. Have you ever worked in finance or banking? I think
your statement holds true only in lectures by college professors or by
people outside of finance. In the latter case, the object isn't the
account, but the name of the account (sometimes called its account
number). Can you give me a single example in the software of a real
financial institution where the balance is actually stored as a data
member of an object in memory?

I have yet to watch your presentation (though I am very much looking
forward to doing so), and I know that you and Trygve generally know what
you're talking about. So I may be a fool rushing in where angels fear
to tread. But...

I cannot imagine *not* representing a bank account as an object in a
bank software system. The balance is part of such an object's state.

After you answer that, we can discuss the difference between
object-oriented programming and class-oriented programming. One of the
major features of DCI is that it supports object-oriented programming.
Very few languages support object-oriented programming directly: they
support class-oriented programming instead.

Often quite true.

You are perhaps suffering from being trapped in the old paradigm, where
everything must be an object. Stick with me here for a few paragraphs as
I explore this. You would have been an excellent student of Kant. In
fact, if you look at people's mental models of their worlds, they think
of much more than objects. An ID number is not an object: it is a handle
to an object.
Agreed.

An account is not an object: it is a role that several
objects together can play.

Not necessarily agreed. In the example below, you're talking about
accounts as objects while claiming you're not doing so.

Do the following experiment. Go to someone who has recently done a money
transfer in their bank. Ask them to give you a general user story for
it. Inevitably, I find people saying, "I decide on an amount, and then I
witdraw that money from one account and put it into another account." If
they speak more precisely they will use terms like "source account" and
"destination account." A "source account" is not an object. It is a role
that something can play (like a savings account).

I believe that you're getting trapped by ambiguous language here. A
"source account" is not an object, to be sure, but that doesn't mean an
*account* isn't an object. "Source account" and "destination account"
are roles, but only accounts (or objects that behave like accounts) can
play those roles, it seems to me.

In Ruby:

def transfer(source, destination, amount)
...
end

peter = Account.findpeter)
paul = Account.findpaul)

Now we have handles to Peter's account and Paul's account. Of course we
don't have the accounts themselves, but we have object representations
of them.

Now we can do
transfer(peter, paul, 100)
in which case peter plays the role of source account
or we can do
transfer(paul, peter, 100) in which case paul plays the role of source
account. Where's the problem here?

For the time being we can pretend that savings account is a class whose
objects can play the role of "source account." That fits the simple
Kantian model of the world, where most things must be objects. But if we
go more deeply, to the level of that domain (in the sense of DDD) we
find that it is not an object — certainly not in the "D" sense of "Data"
in DCI. It is a collection of use cases, of behaviors.

The point of a "traditional" object, it seems to me, is that it unifies
data and behavior in one package. DCI may be a valid form of analysis,
orthogonal to "traditional" object analysis, but that doesn't mean that
objects revealed by traditional object analysis (such as the Account
instances in your example) aren't objects.

Best,

 

[James Coplien]

James Coplien wrote:
[...]

I cannot imagine *not* representing a bank account as an object in a
bank software system. The balance is part of such an object's state.

No. In every example I've seen, financial records are kept as audit
trails that track deposits, withdrawals, interest accruals, etc. There
is no "balance" sitting on a disk nor sitting in memory. The balance is
computed as the sum of accruals, less the sum of decreases, against some
baseline. All these data are in a database — but no balance.

Let me reiterate my question, which yet goes unanswered here: Can you
name me one, real, concrete system in real use, in a real financial
institution, where the account is an object, and its field is a balance,
within a system that manages the account itself?

Not necessarily agreed. In the example below, you're talking about
accounts as objects while claiming you're not doing so.

I start talking about them as objects as a way to introduce the concept.
Then I move to the real design to introduce how Contexts can replace
objects in some contexts.

I believe that you're getting trapped by ambiguous language here. A
"source account" is not an object, to be sure, but that doesn't mean an
*account* isn't an object. "Source account" and "destination account"
are roles, but only accounts (or objects that behave like accounts) can
play those roles, it seems to me.

I agree that this is an issue of misunderstanding. Your code example has
nothing to do with the point I'm making. Think of the point I'm making
as having to do with the psychology of perception (which is what Dahl
and Nygård viewed OO as being all about in the end). In your example,
peter is a name for an identifier which contains a reference (an
address, another kind of name) of something called an account. That it
can be an object in Ruby doesn't mean that it properly reflects the
proper mental model. For example, I can also do this in Ruby:

def account (account_id, amount)
. . . .
end

So what? And I have the same "so what" reaction to your code.

I agree with your above analysis that accounts, or objects that behave
like accounts, can play these roles. Can my phone bill play the role of
an acccount? If it does, is it an account in the banking sense? Of
course not. But I can transfer money to it — because it can play the
role of a source account. So it *can* be a data object. My point is that
it doesn't have to be, and that in fact, very few accounts are. They
rather are Contexts than Data objects.

This facet of the underpinnings of DCI is not about language expression,
but of about how we think. That's the paradigm shift part.

 

[Marnen Laibow-Koser]

Thanks for replying! I've probably injected myself into a debate that's
a bit over my head, but that's how learning happens.

James Coplien wrote:
[...]

I cannot imagine *not* representing a bank account as an object in a
bank software system. The balance is part of such an object's state.

No. In every example I've seen, financial records are kept as audit
trails that track deposits, withdrawals, interest accruals, etc. There
is no "balance" sitting on a disk nor sitting in memory. The balance is
computed as the sum of accruals, less the sum of decreases, against some
baseline. All these data are in a database — but no balance.

That's implementation. It is irrelevant to interface, no?

Let me reiterate my question, which yet goes unanswered here: Can you
name me one, real, concrete system in real use, in a real financial
institution, where the account is an object, and its field is a balance,
within a system that manages the account itself?

First, your question probably goes unanswered because the only people
who could answer it are people who've worked on the proprietary systems
in question. I have the impression that not much financial software is
open source.

Second, it's irrelevant whether balance is a field or a calculation, at
least if the uniform access principle is still to hold. As a
hypothetical user of class Account, I want to be able to call
Account#balance and get a balance. I don't care in the least what has
to go on to get me that balance.

I start talking about them as objects as a way to introduce the concept.
Then I move to the real design to introduce how Contexts can replace
objects in some contexts.
OK.



I agree that this is an issue of misunderstanding. Your code example has
nothing to do with the point I'm making. Think of the point I'm making
as having to do with the psychology of perception (which is what Dahl
and Nygård viewed OO as being all about in the end). In your example,
peter is a name for an identifier which contains a reference (an
address, another kind of name) of something called an account.

So far so good.

That it
can be an object in Ruby doesn't mean that it properly reflects the
proper mental model.

I think of an account as being an object. Doesn't that make it the
proper mental model for me?

For example, I can also do this in Ruby:

def account (account_id, amount)
. . . .
end

So what?

I don't get your point here at all. Please elaborate.

And I have the same "so what" reaction to your code.

Why?

I agree with your above analysis that accounts, or objects that behave
like accounts, can play these roles. Can my phone bill play the role of
an acccount? If it does, is it an account in the banking sense? Of
course not. But I can transfer money to it — because it can play the
role of a source account. So it *can* be a data object.

Uh, what? You can't transfer money to your phone bill. You can
transfer money to your account at the phone company -- and you can do so
precisely because it is (or behaves like) an account.

My point is that
it doesn't have to be, and that in fact, very few accounts are. They
rather are Contexts than Data objects.

And I really don't see where you come to that conclusion.

This facet of the underpinnings of DCI is not about language expression,
but of about how we think. That's the paradigm shift part.

Yes, but I so far do not agree with your premises here, which means I
can't agree with the paradigm that develops from them. I'm certainly
willing to be convinced, though.

Best,

 

[James Coplien]

Let me respond to bits of Marnen's excellent post at a time.

Thanks for replying! I've probably injected myself into a debate that's
a bit over my head, but that's how learning happens.

For all of us

James Coplien wrote:
[...]

I cannot imagine *not* representing a bank account as an object in a
bank software system. The balance is part of such an object's state.

No. In every example I've seen, financial records are kept as audit
trails that track deposits, withdrawals, interest accruals, etc. There
is no "balance" sitting on a disk nor sitting in memory. The balance is
computed as the sum of accruals, less the sum of decreases, against some
baseline. All these data are in a database — but no balance.

That's implementation. It is irrelevant to interface, no?

It affects the internal form of the system. That form is called its
architecture: the parts and their relationships. Those parts have
interfaces, and the way we think about them affects the way they are
implemented in the code.

For example, if we implement a bank system in terms of incremental audit
trails and dynamic association between those elements and roles that
appear in dynamically created account Contexts, it's a much different
design than if an Account is a data object. It shows through. Kent Beck
has long argued that you can't hide a bad design behind a good
interface. Brenda Laurel emphasizes the importance of the direct
manipulation metaphor. Alan Kay talks about these objects as extensions
of the images of your own mind. That is what DCI is trying to do.

More to the point, the way that the market thinks about them (the
stakeholders) affects their rates of change. Much of design is about
eliciting change points so that frequently changing stuff is easy to
change, is localized, and is separated from the stuff that doesn't
change so much. That isn't all in the interface, unfortunately. In fact,
it is often just the opposite. Most of the interface of a Prius car is
the same as that for an ordinary gasoline-powered automobile, but the
internal architecture is radically different.

First, your question probably goes unanswered because the only people
who could answer it are people who've worked on the proprietary systems
in question. I have the impression that not much financial software is
open source.

O.K., well, I can speak for what I have seen in Saxo Bank, in Swiss Bank
Chicago, in Swiss Bank London, in Allianz, in a large Danish pension
company and in many other discussions with financial people at
conferences. Even Ron Jeffries' XP book features a user story that
describes an account balance in these terms. If you have done your
domain analysis, these things are obvious to someone in the business.

Another obvious failure is that people designing a telecom system
thinking that a phone call is an object. It isn't an object in any phone
system I've seen. I've seen many inside AT&T and Western Electric, and
publications from Bell Northern Research / Nortel indicate that also
avoid this failure mode. The same was true at Avaya, AGCS, ... shall I
go on?

The problem is that objects became really popular in the industry in
about 1990 and now everything that is a Thing has to be an object. The
naivté was fueled by early methodologists who told us a number of silly
things: everything is an object; objects should be created in isolation;
objects are the nouns in your requirements document; and so forth.

And so we have a claim here about accounts being objects,
unsubstantiated in reality, but based in such an overwhelmingly strong
mythology that it prompts multiple denials about the claim of how real
systems implement this. It is a matter of maturity. It is easy to
stumble into a great tool like Ruby and to look for ways to apply its
class facilities to everything in site. But there are much more subtle
structures at work here. What's really cool about Ruby is that rises
even to this challenge. (Most languages can express DCI concepts in some
degree. There's only one popular language that can't, and I'll let you
figure that out. Class, that's your homework assignment for tomorrow.)

The popular, naive claim doesn't work in practice — which is why you
don't see it in practice. Let's contemplate your account example with a
balance as a member. What is the object's scope? Its lifetime? How many
of these objects exist in a banking system? How is concurrency handled
(that's the killer): when the actuaries and account holder and the bank
want to access it at the same time? What is the scope and duration of a
transaction in terms of the object? If you have transaction semantics
(and all banks do, to avoid losing money under concurrency) what is the
mapping from the object model to the transactional model and the
relational model that usually supports it? Remember: Ontos and its
cousins were largely failures, because they tried to stay in the
paradigm of your grandfather's object-oriented architecture. The
complexity just got out of hand.

DCI actually offers reasonable answers to all of these questions,
because it's rooted in structures that can capture and express higher
levels of complexity, both static and dynamic, than a POJO approach can.
I think that's what got this thread started: I described a solution to a
problem that is more complex than people can conceptualize using their
grandfather's object-oriented programming, and understanding broke down.
I think that people fail to understand it's a paradigm shift — but
that's maybe a liability of taking one's understanding from a few hours
of videotapes.

Second, it's irrelevant whether balance is a field or a calculation, at
least if the uniform access principle is still to hold.

That claim holds only within a single contextual thread. Another set of
immature foundations can be found in the Agile world where we are
supposed to be focused on the customer. And most of the naive claims
about accounts here come from that perspective. I can just read the user
stories and use those to drive my design, using TDD or something else.
Just find all the elements of all the interfaces and just organize them.

The fact is that most of the computation in a bank has nothing to do
with someone who has an account, but who is in the back office managing
investments or doing analyses. They're called actuaries in English.
Actuaries care little about the status of your bank account. They care
about the transactions.

There are many other sets of users who are looking at these data:
auditors, tellers, ATM machines, other banks, the national bank,
investors, loan officers, bank executives. All you need to do is to take
all the responsibilities of all those stakeholders and divide them up
into nice interfaces that give you nice objects that have nice coupling
and cohesion. It's intractably complex.

DDD has recently drawn attention to the importance of unearthing domain
concepts that are stable over time. They have little to do with the
requirements of the stakeholders. Very few people understand that. The
"dumb" data objects of DCI come from this domain analysis; they are
often the model objects one finds in MVC. The intelligence that serves
the actuaries, the accountants, the loan officers and everyone else play
out in use cases that are defined in terms of roles — roles that are
mapped onto the right domain objects at the right time by the right
context.

The essence of an object-oriented system is that the mappings from roles
to objects changes thousands or millions of times a second. Your
grandfather's OO simulated a very weak version of that called inclusion
polymorphism. The DCI mapping brings these dynamics to the surface.

As a
hypothetical user of class Account, I want to be able to call
Account#balance and get a balance. I don't care in the least what has
to go on to get me that balance.

So you don't care about its data. It is essentially a service, a
computation. We collect those services together in DCI and call them
Contexts. You instead are trying to convince me that they should be
objects. O.K., a Context is an object by some definition, and if that's
enough for us to agree, then we agree. But it is not a domain object —
that creates an architecture where the pressure points of change are all
in the wrong place. A simple domain analysis of a financial application
will bear that out quickly.

More to the point, it is useful to distinguish between objects (as Dahl
or Nygaard would recognize them) and the roles that they play. If
programming language is to be about intentionality (communicating the
design intent of the programmer) then we want the programming formalisms
to carry this distinction forward. That's what DCI is: a set of
formalisms that carry archetypical elements of human cognition and
machine computation forward into the code.

Calling it an object is a little like calling it a thing. I want a
little more insight from these labels.

I think of an account as being an object. Doesn't that make it the
proper mental model for me?

No, you're a programmer. And that's O.K.: programmers are people, too,
and we need to support ehir model. But, again, object orientation is all
about capturing mental models in code, and we need to be attentive to
stakeholders other than the programmer. Like Raskin said: The interface
is the program. A user experience person would pursue this issue using
the kind of question I posed in an earlier post, leading to the
description (e.g., for a money transfer) that I think about things in
terms of source accounts and destination accounts. Unfortunately, my
bank doesn't have source accounts. I can conceptualize a source account,
but can't create one, can't open one, can't find one. They're not
*objects*. They're protocols, or interfaces to objects. They're roles.
Those, too, are part of our mental models. And they should be part of
the code as well. If you look at where Rebecca Wirfs-Brock has taken
responsibility-driven design, it is into this realm of roles. Objects
don't have responsibilities; their roles do. That was the conversation
that Trygve and I recall from his discussion with Rebecca on the deck of
the Hurtigruten all those years ago. There are some additional concepts
that we should be attentive to as well, including algorithms and the
associations from roles to objects. DCI packages most of these in roles
and Contexts.

If all you have learned is objects, then everything to you is an object.
That is whey I said you might make a good student of Kant. A good
exploration of end-user mental models shows that they are much more
subtle. Introducing roles provides a much better match for this model
and provides a much better foundation for good software structure than
the pure object approach does. Trygve published some preliminary metrics
about this on object-composition, and you might have a look at them and
at the surrounding discussion.

Uh, what? You can't transfer money to your phone bill. You can
transfer money to your account at the phone company -- and you can do so
precisely because it is (or behaves like) an account.

No, the entity I manipulate on my web page is exactly my phone bill.
(Denmark has an advanced banking system, so maybe those of you in other
countries still do this with checks to the phone company and so forth —
but even for one of my accounts outside Europe, I can treat the phone
bill as an entity.) That's my mental model. It's not that I'm paying the
phone company; I pay my phone bill. No one says at the end of the month
"I need to pay my phone company." They say "I need to pay my phone
bill."

And I really don't see where you come to that conclusion.


Yes, but I so far do not agree with your premises here, which means I
can't agree with the paradigm that develops from them. I'm certainly
willing to be convinced, though.

I'm still awaiting concrete examples that are different than those
banking examples that provide much of the background for my premises. In
any case, it shouldn't matter if you are trying to understand. Adopt my
assumptions arbitrarily if it helps you see the ideas more clearly and I
can provide the documentation later. I think that if you explore the
real world you'll see that my assumptions hold.

I hope this helps. I really appreciate your specific and forceful
questions — I think it helps me communicate my ideas more concretely.

 

[Sean DeNigris]

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