"A use case is not an algorithm because a use case can be non-deterministic"
"DCI is really about capturing the algorithms in a framework that reflects the use cases"
"Good objects are dumb, not smart...and that's probably against what your professors told you"
"One of the important things about your grandfather's object-oriented programming is that you couldn't reason about the state of the system. You could only reason about the state of an object. "
"TDD is about the state of an object that has no business value"
"Keep use-cases goal driven, and use habits for these things at a lower level [i.e. the 'include's of use cases]"
"A withdrawal is a fairly complex business practice. It doesn't belong in a dumb object [e.g. savings account - re: decreaseBalance vs. withdraw]"
"Customer says, 'I want this account to pay all my bills'. Ok, well define some roles from the use-case 'pay all bills' and will inject the right parts of this use case into this class [savings account] at run time to make it do what it needs to do. And then we don't have to worry about this dumb domain class. That can remain relatively stable. Good design is about separating what is stable from what changes. "
"'transfer funds' is a use-case. How do I represent use-cases, well, as a context"
"All [the context 'execute' method] does is say source account.transfer to, and the rest just happens because all the wiring has been done here [context initialization], we just go to the first role in the use-case, initiate it with an event, and the rest just happens. This 'execute' in context is a way of stacking the context. Contexts stack. ... I can call a context. This is a way of reusing use-cases or really, re-using habits, where I can build a context that represents a habit, and call it from another use case. "
re: "chunking," " It might be nice to have this full use-case laid out before you, but you couldn't understand that anyhow. We understand things by well ... two different cognitive tools. One is divide and conquer (or partitioning) and the other is compression, and we need both; and so this notion of context is the way of doing divide and conquer, of splitting things up into units of use cases that we can understand. Roles are a further chunking of functionality ... "
"I said that an account is an object right? I lied. ... what are the objects in a bank, are they accounts? what are the objects? transaction logs, audit trails. What is the balance on your account? It's the iteration over an audit trail, adding up all the deposits and subtracting all of the withdrawals. Your balance isn't sitting on a disk somewhere, it's computed, it's a use case! An account isn't an object. The account ID might be an object, but the account is an active thing -- in your terms a business process. ... What is an account in DCI, because if it's an object, then its a domain object and has to be smart; and we don't like smart domain objects, they don't evolve well. ... It it part of the user mental model? Of course. We talk about accounts, so it must be a thing if we're doing object-oriented programming which is capturing the end-user model in the code, then it [the account] should kind of fly like an object, quack like an object, and walk like an object. Well what is it? It's a context [ see also how inbox is a context, i.e. InboxContext]. What is a context? A context is a use-case. Well can we make a context to be a collection of related scenarios that involve a certain set of roles? What is a collection of related potential scenarios between an end-user and system under construction? That's a use case. And we reflect it in DCI as a context object. "
"Roles ... have the algorithms in them but they really don't have state. Most roles in DCI are stateless. They are pure algorithm. The state has to be remembered in the domain objects. And each role works with one ore more contexts or gets injected into some domain object, so that contexts can organize their bindings and kick off new executions as events come in. But it turns out that contexts [ points to blue ball on path between role and domain object pink ball] ... can behave like domain objects, like...savings account does. It's not an object, it is a collection of interactions between roles around a set of scenarios [see 'scenario' in BDD] that we call use-cases. And so this kind of solves a very very very longstanding problem in object-orientation, 'cuz everyone wants to make an account an object, and it really isn't. And there's all kinds of problems with the lifetime of these ideas if you treat them as objects. It's the algorithms of the account that are long-lived, and the identity of the account. The account identity may be a long-lived object, but not the account. Things like the account balance are very ephemeral. So they're computations. We now have architectural home for these computations that you don't find in most object-oriented methods.
"I said that domain models should be dumb. Do I have any rules for saying what things should go there and what things don't. It has to do with this concept of shear layers [layers of maintenance frequency, see house architecture] and understanding how stable are things. And so you go to something like Eric Evans book on domain driven design, and you look for the things that are stable. Those are the things that I want in my domain model. If things are going to be part of things I sell to the business that are going to be more dynamic, I want those in the roles [above]. So ... another way of looking at it; it's a dichotomy of what the system is and what the system does. So the domain model, the dumb dumb dumb classes down there are what the system is, so a system is transaction logs, audit trails, what it does is transfer money and pay bills. ... [explains how 'domain model' or 'data model' is the D in DCI and M in MVC]... This is the programmers side of MVC MVC is the end-user's side to get their mental model lined up; [DCI] is getting the programmer's mental model lined up. Same model, same 'M'.
James O. Coplien
http://vimeo.com/8235574
No comments:
Post a Comment