Tue Jun 24, 2003 10:12 pm
Eric,
I recently downloaded your book and have been reading through it as
time permits. I am a newbie when it comes to OO*. From the books and
articles that I have been reading, your book is one of the very few
which talks about the importance of domain design.
My problem with methodologies like Agile and XP is that they tend to
ignore the big picture in a hurry to get into design and
development. "Traditional" methodologies like IE lay a huge
emphasis on understanding the AS-IS and the TO-BE of a business
process and identifying business process re-engineering requirements.
The Agile/XP processes are geared towards a "learn as you go
long" approach. This lack of "big up-front" leads to fractured
domain models. The cost of re-factoring a domain model is huge (as
you have also noted in your share-pie example) and the costs increase
with every iteration.
Some may claim that this problem can be mitigated by
implementing "enterprise patterns" (e.g. Fowler). The problem
with patterns approach is that a pattern solution can be applied only
after the problem is identified as a pattern.
HemantSahgal
Hi, Hemant. Thanks for the comments.
I agree and disagree.
True, refactoring domain models can be very expensive. But costs
don't necessarily increase with each iteration. Keeping that cost
down is one of the benefits of a supple design.
Also, as expensive as refactoring is, it can be a lot less expensive
than sticking yourself with a naive, early model and design. The
learning curve is so steep on a good software development project
that the models possible at later stages will be incomparably more
useful than those proposed early on. I change domain designs, and
change them and change them. And they become more supple along the
way, which helps control the cost -- some.
Where I do part ways with many XPers (though I am by no means alone)
is on the amount of work I'm willing to put in to have model objects
that actually carry meaning, rather than taking the most direct path
to implementing the functionality of the first iteration. Everyone
agrees that duplication is unacceptable. For me, it is also
unacceptable not to have your current understanding of key parts of
the domain reflected clearly in the code.
I view it as an essential part of development, even in the first
iteration, to capture the knowledge related to that iteration's
functionality and crunch it into the model. Then, in the second
iteration, your eyes will be opened and you'll end up refactoring
those old objects. Then in the third iteration you'll REALLY
understand them and you'll refactor them. Or at least you though you
really understood them, but then in the sixth iteration...
Ah, but you can't do that for everything in the system. Hence all the
talk in Chapter 15 about the core domain and so forth. Only parts of
the system deserve that kind of investment. Others merely have to be
good enough, and will (we hope) stabilize.
I do agree with you on the importance of having a big picture. I
think that is what the "system metaphor" of XP is reaching for,
although it only covers a few cases. So Part IV of the book is all
about the big picture. But that big picture has to evolve, too. (And,
yes, it is expensive.)
EricEvans
Hi Hemant,
My problem with methodologies like Agile and XP is that they tend to
ignore the big picture in a hurry to get into design and
development.
Your statement is of great interest to me and brings to my mind two questions. My first question asks: do you believe that somewhere in the scheme of things there is a solution to the relation between design details and how those details can best be fit together to compose an optimum big picture? If you do believe that the two can be optimized, my second question curiously asks: where have you looked to date for such a possible solution to this relation between the development of a design into a satisfactory whole picture?
DanPalanza
Dan/Eric,
Let us consider a Sale event in an enterprise. Logistics will see a
Sale event as an invoice; Accounts will see the same event as a debit
entry for the customer; Sales will see it in terms of an entry
towards meeting their sales target; Stores will see it as a reduction
in stocks; Marketing will view it in terms market penetration etc.
Similarly, other departments will have other views of the data.
The point to note is that all these are very different views of the
same event. The data underlying the event is the same. How this same
data is viewed by different parts of the enterprise is very different.
Getting into design/development very quickly without enumerating,
examining and putting together all the different views can lead to
very process/department centric multiple design models and it becomes
very difficult to assimilate and reconcile all these different views
into a single model late in development.
I am not saying that this problem is unique to OOAD but I think that
going into design/development very early increases the chances of
missing the "big picture" till very late in the development cycle.
"Do you believe that somewhere in the scheme of things there is a
solution to the relation between design details and how those details
can best be fit together to compose an optimum big picture?"
A good Information Modeler will be able to reconcile these views into
a single model "up front". There will be mismatch between
the "conceptual model" and the "physical model" but as long as the
physical model is traceable from the conceptual model it is ok. Which
is why in structured programming the code is important but the core
data model is sacred.
"Where have you looked to date for such a possible solution to this
relation between the development of a design into a satisfactory
whole picture?"
Here are tow places where I have found some good stuff. Good off the
shelf conceptual models can be found/derived from David Hay, "Data
Model Patterns: Conventions of Thought". These models demonstrate
what a good information modeler can do. I have read some of Fowler's
writings (those that are available online).
Unfortunately, most books and articles on OO* focus on very (what I
would like to call) micro-problems requiring code-design solutions
rather than demonstrating the solving of domain problems.
If you know of some other good sources please point them out for me.
HemantSahgal
Hemant, thanks for providing a concrete example. That will help keep
us on track.
Let's talk about the question of how that modeler would reconcile
those views and what form that big picture might take. (We could
probably have a pretty interesting debate about the tradeoffs of
upfront design, but although I have my opinions on that subject,
domain-driven design should work in any process that provides
adequate means of learning about the domain and has feedback.) So,
here are some ways of initially approaching the issue with the tools
in the book.
The first thing I think of with the example you gave is a "context
map" (discussed in Chapter 14). The different departments have
different models. They see the same thing and it means something
different to them. We have some integration needs, so we have to
decide what the relationship of the models in those different
departments is going to be. For me, that means mapping out the way
things ARE, first. Then at least people will be able to have rational
conversations.
In this case, it sounds like we might have a "shared kernel", a
certain part of the model that everyone agrees on, but which they use
in their subsystems in different ways. The "Sale" event is the main
element of that kernel.
Trouble may arise from the teams' lack of recognition that they are
operating in different contexts, where terms mean different things,
yet they are sharing one object. So the logistics people start
tacking on invoice properties and behaviors, the accounts department
starts making it act like a debit, and so on. Optimistically, they
will end up with a bloated jumble. More likely, they will step on
each other and make buggy, self-contradictory software.
On the other hand, if they agree that "Sales Event" (or was
it "Sale") is shared, and work to keep it in common, they will end up
trimming that shared object down to the essence of what everyone sees
as that basic event. Then they will probably create an "Invoice"
object that has a reference to a "Sale". They'll create an "Account
Entry" that references a "Sale", and so on. At this point, we have
minimal, but rational, integration. We have the beginnings of a big
picture (the context map). We have people talking to each other with
clear context for their communication, so that analysis will be more
effective if they take steps to find a deeper model. (After all, this
is just something off the top of my head, and I don't have a deep
understanding of their situation.) They might find a way to unifying
their various models, but not necessarily.
When these things are eventually implemented, I would expect to see a
recognizable "Sales" object in each of those subsystems. It might be
implemented differently, especially if different technologies are
used in different subsystems, but it should be semantically
equivalent, so that translation is trivial. I expect this
correspondence between model and implementation to be very close, or
else the analysis that goes into the model does not give confidence
about the correctness of the software. This is what I mean by
a "model-driven design". Of course, many implementations might map to
the same model, but I do not mean by this just traceability. I mean
an obvious, quite literal mapping between concept and software
artifact.
EricEvans
Hi Hemant,
Let us consider a Sale event in an enterprise. Logistics will see a
Sale event as an invoice; Accounts will see the same event as a debit
entry for the customer; Sales will see it in terms of an entry
towards meeting their sales target; Stores will see it as a reduction
in stocks; Marketing will view it in terms market penetration etc.
Similarly, other departments will have other views of the data.
Even though stakeholders may see the Sale event differently, essential facts are present that each user (stakeholder in the sale) holds in common: (1) is that ownership of something of value has changed hands by virtue of a sale and (2) all parties need an addressable record of what has changed. Therefore an optimum model has two requirements: (1) to record a history of change that is universally addressable by (2) many users of that one history.
Such a modelling technique, which predates software development by about 600 years, is present in double entry bookkeeping.
>The point to note is that all these are very different views of the
>same event. The data underlying the event is the same. How this same
>data is viewed by different parts of the enterprise is very different.
Because you come from a data-modelling background your sense that something fundamental is missing in Agile/XP may well be valid. I will argue that you hang on to your discomfort for awhile, there may be good reason for it.
>Getting into design/development very quickly without enumerating,
>examining and putting together all the different views can lead to
>very process/department centric multiple design models and it becomes
>very difficult to assimilate and reconcile all these different views
>into a single model late in development.
Here you would do well to make clear the your distinction between the design of a data model, which includes the Sale event, which all of the users will want to address, from the design of the programming rules that will create that ideal data model.
>I am not saying that this problem is unique to OOAD but I think that
>going into design/development very early increases the chances of
>missing the "big picture" till very late in the development cycle.
Once you distinguish between the data model you wish to achieve, as a complete system, and the programming rules that will enable an optimum user-language to address that data, I believe you will find a natural tension exists between data's role as a functional model, and programming's rules that form the data model's control language. Where the data system is being geared up to handle huge complexity, programming's rules are being refined toward extreme simplicity. These conflicting rationales are in fact complementary contributors to what I believe is your goal.
In my experience researching double entry bookkeeping it is this natural tension between a data system's need for role complexity versus a control language's need for rule simplicity that led to bookkeeping's double entry model. In a proper bookkeeping framework the physical history of changes is first modelled into a "Debit System" which in turn is controlled by "Credit Language." Now whatever you name these categories, "XP" versus "The Big Picture," you will find that the two differ as categorically different rationales. It is the conflicting rationales that force their separation into double entry.
I asked:
"Do you believe that somewhere in the scheme of things there is a
solution to the relation between design details and how those details
can best be fit together to compose an optimum big picture?"
A good Information Modeler will be able to reconcile these views into
a single model "up front". There will be mismatch between
the "conceptual model" and the "physical model" but as long as the
physical model is traceable from the conceptual model it is ok.
In double entry bookkeeping we call this traceability between "Physical model" and the "Concept Model" an "Audit Trail." When the bookkeeping framework is software driven, the audit trail is a reusable history. Debits form a functional data model of the actual "Physical Model," such as the Sale event of which you spoke, and credit forms a control language as programmed rules by which the data is modelled into an environment of interests. The many data users are interested in this environmental model. They are happy to trust that the programmer has gotten the "Physical Model" correct.
>Which is why in structured programming the code is important but the core
data model is sacred.
Ditto for double-entry bookkeeping, but only because the rules of the "Concept Model" in double entry bookkeeping have been refined to a universal simplicity, which enables any level of complexity in the data model that a community of users require.
I asked:
"Where have you looked to date for such a possible solution to this
relation between the development of a design into a satisfactory
whole picture?"
Here are tow places where I have found some good stuff. Good off the
shelf conceptual models can be found/derived from David Hay, "Data
Model Patterns: Conventions of Thought". These models demonstrate
what a good information modeler can do. I have read some of Fowler's
writings (those that are available online).
Here is where the categorical rationale between a "Physical Model" and a "Concept Model" come into play. Data modelling has two types of rationale. I have read Hay's book. For relational database modelling it is excellent. The relational database is great for plotting an image of the "Big Picture," as the "Concept Model." But because the rationale in a relational data model takes the form of a graph, it breaks down completely when serving the needs of a reusable "Physical Model." The problem has to do with time as a variable. (This argument is covered in detail in "Structure and Interpretation of Computer Programs," by Abelson, et al, as the distinction between a substitution model versus an environmental model. In double entry bookkeeping the debit system uses the rationale found in the substitution model, whereas credit language, if the history is to be reusable, must resort to a technique such as "Steams" if the environmental model is also to be reusable.)
In double entry bookkeeping this distinction between the two rationales gives rise to the journal versus ledger pattern. The journal is a network of reusable--substitutable--roles played by data, which, as data points, is then cast into the static image as a ledger. The stakeholders in your "Sale event" will invariable want to cast an image of that one transaction in a graph of their choosing. Once data is in relational form, one looses the time factor as a variable. And so the bookkeeper always works from functional data points as journal data cast into and informational image as a ledger. The ledger is an image at a particular point in time.
>Unfortunately, most books and articles on OO* focus on very (what I
would like to call) micro-problems requiring code-design solutions
rather than demonstrating the solving of domain problems.
When a proper bookkeeping fell through the software development cracks 30-50 years ago, the alternative has been to attempt to create a static model of the enterprise. This has led to some notable failures, such as Enron, WorldCom, Tyco, and a host of others that now even includes Freddie-Mac. Bookkeeping errors in the billions of dollars could never occur had these companies been using a proper double entry framework to model their data (there would be too many honest people in the company using the common data model for the error to go undetected). The analogy is to a major building or bridge collapsing. When such calamities occur, something fundamental is going wrong. And so I, for one, commend you for calling to our attention your discomfort with Agile/XP.
Ralph Johnson's defense of "Agile/XP" is valid, but he also points out that the words "Agile" and "XP" were not in the software vocabulary six years ago. I believe Ralph's comments point to software development's life cycle is still a ways from its final evolution. So long as major corporations are collapsing, you can be sure there will be new words to reflect new concepts.
>If you know of some other good sources please point them out for me.
People often ask me for sources relative to bookkeeping. The only treatise I have ever found on double-entry bookkeeping that covers all of the issues that enable the construction of a proper framework was written in 1494 by an algebraist named Luca Paciolli. And the only way I know of to understand his reasoning, his pattern of rationale, is to actually build a bookkeeping framework. I have built such a framework and so I know that it does work. A list such as this one, it seems to me, is an ideal place to bring this dusty old literature back to life.
DanPalanza
Dan
>
> Such a modelling technique, which predates software development by
about
> 600 years, is present in double entry bookkeeping.
This is interesting. I have been building software based on the REA
accounting model for the last two years. I would like to know more
about modelling based on double entry. However, I dont think that
this group will be the right place to persue it.
HemantSahgal
Hi Hemant,
>This is interesting. I have been building software based on the REA
accounting model for the last two years.
I would like to hear how REA is working for you. When McCarthy spoke of it on the Patterns-Discussion list in '96 he pooh-poohed double entry as a vestige of paper bookkeeping that is no longer essential when doing accounting on a computer. In fact, it was his gross misconceptions of what bookkeeping is that moved me from a casual study to an intense study of it since then.
>I would like to know more
about modelling based on double entry.
In double entry bookkeeping one sets up a simple framework of rules that provide a test for completeness and balance of all transactions that affect the entity being tracked. Once the test is in place, all accounting is performed, hence all accounting code is created, subject to this test.
It is ironic that at just about the time McCarthy was downplaying the bookkeeping test on the patterns list, Beck was going to work for Chrysler where XP jelled, and writing test code became as important as writing application code. For business software, I can assure you that the bookkeeping test is many magnitudes ahead of any test of application code that XP has discovered to date. Beck got the test principle correct; but he would now do well to review the history of testing procedures, such as double entry bookkeeping.
>However, I dont think that
this group will be the right place to persue it.
I am extremely interested in hearing why you feel that way. Your original post to this thread raises a classic bookkeeping issue. The bookkeeping notion that assets are always equivalent to liability is nothing more than the law of conservation of energy. The big picture then asks, Is this project--writing new code, or improving old code, for example--going to increase of decrease entity's potential to do successful work in its environment?
Where assets are entity's subject actions, liability is entity's object reaction. The cost to write code is clearly valued according to that code's ability to increase entity's subject strength (to draw from its environmental object, where goods and services are traded). Therefore a budget is a critical aspect of writing code.
A budget is nothing but a proposed, or anticipated, bookkeeping result, as opposed to the actual set of transactions that follow the budget (hopefully). It seems to me that a well refined bookkeeping method will supply the big picture that you are looking for.
If that is so, why would a list that seeks to extend XP and Agile, where the big picture is clearly missing, not be a good place to bring the bookkeeping pattern into focus? I say "pattern" because from 1996 to now, I have proven to myself, beyond doubt, that double entry bookkeeping has worked for 600 years because it follows a universal pattern language.
DanPalanza
Eric,
I am fully for domain driven design!
...domain-driven design should work in any process that provides
adequate means of learning about the domain and has feedback...
...We have some integration needs, so we have to decide what the
relationship of the models in those different departments is going
to be. For me, that means mapping out the way things ARE, first.
Then at least people will be able to have rational
conversations.
Isn't that what IE is all about - domain driven analysis and
design?
...it sounds like we might have a "shared kernel", a certain part
of the model that everyone agrees on...
Generally, the "shared kernel" is hidden from the users. There is
a need to bring it out into the open and this can happen only with
integrating the models very early or trying to build an enterprise
model to begin with.
My problem is how to reconcile the domain design(s) with the big
picture. Of the couple of books on OO that I have read, yours is
the only one which advocates tending to the domain model. Most
books teaching OOAD tend to favour Agile/XP methodolgies. Most
books tend to make a direct jump from use cases to object
interaction to class diagrams. Others talk about the domain model
but say that it should be discarded after a couple of iterations
[Larman - Applying UML and Patterns; Scott Ambler - Agile Modeling
site].
HemantSahgal
Well, I do advocate Agile/XP methodologies, but I don't want to entangle the issues too much, and I'm open minded about different approaches.
I'm not sure what you mean about the shared kernel being hidden from the users. I agree that it needs to be brought into the open, since it is centrally important. But why can this only happen very early? Now, I agree that it is important to tackle integration very early, but what if you are not at the beginning now? There is an existing system that you are trying to solve problems in, perhaps.
When Larman and Ambler talk about discarding the domain model after a few iterations, do they mean to abandon modeling, or to expect to change your model beyond recognition (essentially discarding it, to make way for a new one)? Could you make a more specific citation?
But I agree that the interesting question is how to reconcile the domain design with the big picture. (I spent the last third of the book on that.) Object modeling is usually a bottom-up kind of thing, which makes this a real issue. But a context map and large-scale structure can give some top-down view, and identifying the core domain can help reduce clutter.
EricEvans
As I said in my first mail I am an object newbie. I come from a data
oriented backgroud where we try to capture the domain in a conceptual
model and then translate the model as a data model. I am trying to
come to grips with this paradigm.
About the shared kernel being hidden: generally the target users are
experts in their own domain (departments) and not very clear about
how things work in other departments. It is only after bringing
together the information from all the users/departments can one see a
shared kernel - hence the requirement of early integration.
I cannot Larman as I do not have the book on hand.
Let quote Scott Ambler from his web site
(
http://www.agilemodeling.com/artifacts/ormDiagram.htm).
ORM diagrams ... are in my opinion an incredibly effective way to
explore domain concepts with your stakeholders.
...
How do you remain agile when working with ORM diagrams? I prefer to
use ORM diagrams with my stakeholders, modeling around a whiteboard
with them in order to explore the problem domain. ... Once we
understand the issue that we're exploring with an ORM diagram I
typically capture the information in another artifact, such as a UML
class diagram or source code, and erase the diagram once I'm through
with it.
HemantSahgal
From: "hemant sahgal" <hsahgal@r...>
My problem is how to reconcile the domain design(s) with the big
picture. Of the couple of books on OO that I have read, yours is
the only one which advocates tending to the domain model. Most
books teaching OOAD tend to favour Agile/XP methodolgies. Most
books tend to make a direct jump from use cases to object
interaction to class diagrams.
This is a bit off the subject, but I don't want to let you make
this mistake in public.
You are either reading an odd collection of books or not interpreting
them correctly. None of the books that are more than four or five
years old explicitely favour Agile/XP methodologies, except perhaps
the one by Wirfs-Brock, Wilkerson and Weiner, and that was written
ten years before people used the name "agile" for software.
It is true that most books do not give much practical advice about
making domain models. This has nothing to do with whether they
favour agile methods. In fact, "Domain Driven Design" is extremely
compatible with agile methods. If you think that it is opposed to
XP then you are not reading it properly. DDD is about developing
your domain model iteratively, by refactoring.
RalphJohnson
From: "h_sahgal" <hsahgal@r...>
My problem with methodologies like Agile and XP is that they tend to
ignore the big picture in a hurry to get into design and
development.
Words like "ignore" and "hurry" are fighting words. You are not trying
to understand XP, you are just reacting against it.
Kent Beck develops good domain models. When he writes books about
developing software, he doesn't talk about that much, because he is
focusing on what he considers more fundamental problems; lack of testing,
lack of feedback, tolerance for unnecessarily complex design. If you
can't solve these problems, you will not be able to develop a domain model
very well. Domain modeling is more advanced than the basic software
development cycle taught by XP.
XP is a minimalist methodology. It describes a few things you are supposed
to do, but expects that you are going to have more practices. It doesn't
talk about OO design at all, because it can work if you are developing in
perl or Lisp. Some projects need a good domain model. Others don't.
XP practices are supposed to be applied to all XP projects, whether they
need a domain model or not.
In contrast, a methodology like RUP includes everything you are ever
supposed to want, and you pick a subset of those rules for your project.
RUP is a "union" methodology, XP is an "intersection" methodology.
In practice, you will always add things to XP, and that does not imply
that there is anything wrong with XP. XP has to be modified if you
are building real-time systems, or if you have to be certified by an
outside agency, or if you have developers living all over the world.
(Actually, the last requires a change in XP, not just additions to it.)
This lack of "big up-front" leads to fractured domain models.
I disagree. In fact, "Domain Driven Design" is about how to develop
a domain model during the life of the project. The way I read it,
it is not about up-front design. If you are constantly refactoring
your system then you do not have to have a factured domain model,
though of course constant refactoring does not in itself make sure
you have a unified domain model.
The cost of re-factoring a domain model is huge as you have also
noted in your share-pie example) and the costs increase
with every iteration.
If this happens, you don't know how to refactor, or you are at
least not doing it right. On an XP project, refactoring costs
are constant over time. Large, but constant. Perhaps a third of
your time is spent refactoring. Even so, development goes faster.
But if refactoring costs increase with every iteration then you
are not refactoring properly. That is a key part of XP, and it
is crucial to understand it if you are going to properly evaluate XP.
RalphJohnson
Hi Dan,
This is a part response to your mail.
"However, I don?t think that this group will be the right place to peruse it"
... "I am extremely interested in hearing why you feel that way. Your original
post to this thread raises a classic bookkeeping issue. "
The reason I feel that this is not the right place to peruse this discussion is
that this is a forum for discussing Eric's book and its theme - keeping the
design in sync with the domain model (and the other way round) during the full
software development cycle.
The theme of my mail (which was lost due to my inability to express) was how to
reconcile "part-domain-models" with the "big picture" while doing iterative
design/development. My experience is that development causes developers to shift
the focus on implementation and its problems and away from the domain. Also,
studying "part-domain-models" and integrating them through re-factoring can turn
out very expensive if you find an elegant but radically different model emerging
in a later iteration.
I did bring up the issue of traceability between the "conceptual model" and the
"physical model". I do not know how this traceability is managed in XP and
Agile.
"I would like to hear how REA is working for you."
In the last two years we have been involved in building applications for sales &
distribution based on this model. There is a slight difference between
McCarthy's model and our's. We use a "controller" during the "materialization"
from a "contract" to an "event".
The users find the model very easy to work with. In our model, the system is
divided into processes. The "agent type" (party role) is implicit to a process.
"Events" are recorded in a process. The users can create their own "contracts",
"events" and "resources". The views in the system are based on the processes
(e.g. - the A/R view is based on all events in the invoicing and accounting
process). We have been able to give the users very flexible reporting modules
for different views of the system.
We are paying for this flexibility in terms of database size and performance and
a complicated configuration process. Another problem is that the many of the
users are steeped in double entry accounting and are unable to reconcile to this
way of working - hence my interest in double entry accounting. I am interested
to know if any work has been done on putting a double entry view on an REA
model.
HemantSahgal
Hi Hemant
>The reason I feel that this is not the right place to peruse this discussion is that this is a forum for discussing Eric's book and its theme - keeping the design in sync with the domain model (and the other way round) during the full software development cycle.
The relation between building product and controlling its design is fundamental to all of life. Wherever we decide to discuss bookkeeping, here or on a new list, we will learn that balancing the relation between build versus design (domain system versus control language) is the reason the double entry pattern was refined into being in the first place, 600 years ago.
If there is no positive sentiment to discuss it here, I can set up a new Yahoo list.
>The theme of my mail (which was lost due to my inability to express) was how to reconcile "part-domain-models" with the "big picture" while doing iterative design/development.
This was clear to me in your original post. In bookkeeping this is resolved by separating a debit system from credit language. Debits model workflow, while credit language controls the expression of rights to the ownership of that work. The two differ as an aggregation of physical roles differs from a composition of intellectual rules. Refining physical roles is the "part-domain" you seek, while refining the intellectual rules is the "big-picture" that you also seek.
>My experience is that development causes developers to shift the focus on implementation and its problems and away from the domain. Also, studying "part-domain-models" and integrating them through re-factoring can turn out very expensive if you find an elegant but radically different model emerging in a later iteration.
In my own experience, once the debit system is made to model the aggregation of physical roles, and the credit language expresses a composition of intellectual rules, the physical roles clearly form an arithmetic calculus, while the intellectual rules form a symbolic algebra. In an unrefined workplace the needs of physical role-modelling will continually challenge the order of intellectual rule expression. But since the intellectual rules are being refactored to handle all possible role-models, in due time any configuration of roles will by covered by the refined composition of rules.
This is the basis of the debit system versus credit language, which was worked out in medieval Italy, in the fourteenth century. The essential method of categorization that makes this pattern language work is clearly covered in a treatise on double entry bookkeeping, written by Luca Pacioli, in 1494. The catch is that one would never comprehend these categories simply by reading Pacioli's paper. One has to build the bookkeeping framework to find their boundaries, or rationale. I have not yet seen a software application that even attempts to achieve this goal. I know it is possible in very large systems because it was used in pre-computer days when I worked a GE in the 1950s. And the small prototype I have programmed, which does have the benefits of computerization, works even better yet.
>I did bring up the issue of traceability between the "conceptual model" and the "physical model". I do not know how this traceability is managed in XP and Agile.
Traceability in bookkeeping is called "audit trail." A physical model is gathered as data points into a journal. The journal data is cast into ledgers creating an image, or images, of the big-picture, at specific points in time--daily, weekly, or monthly graphs.
The journal-pattern is a list that forms Streams exactly as the Streams-pattern is formed in the Lisp language. "Cons" is a transaction, or group of transactions to be cast into a ledger. "Cdr" is the list of physical elements. "Car" is the intellectual rule, as operator, that tells where to put the values of the physical list onto the graph, or ledger. The power here is in filtering lists in order to cast a ledger that sees only the "part-domain" one wishes to refine, or the "whole-picture."
>"I would like to hear how REA is working for you."
>In the last two years we have been involved in building applications for sales & distribution based on this model. There is a slight difference between McCarthy's model and our's. We use a "controller" during the "materialization" from a "contract" to an "event".
>The users find the model very easy to work with. In our model, the system is divided into processes. The "agent type" (party role) is implicit to a process. "Events" are recorded in a process. The users can create their own "contracts", "events" and "resources". The views in the system are based on the processes (e.g. - the A/R view is based on all events in the invoicing and accounting process). We have been able to give the users very flexible reporting modules for different views of the system.
>We are paying for this flexibility in terms of database size and performance and a complicated configuration process. Another problem is that the many of the users are steeped in double entry accounting and are unable to reconcile to this way of working - hence my interest in double entry accounting. I am interested to know if any work has been done on putting a double entry view on an REA model.
One's difficulty with (1) database size and (2) moving work-flow results into double entry bookkeeping is a fundamental flaw that has permeated software development since I first bought a computer in 1979. A relational database is essentially a graph, which the bookkeeper calls a "ledger." By skipping the use of a journal pattern--where data is kept in a network architecture--and posting data directly from transaction to a graph, is that one's rationale when refining the model is that data becomes graph-back-to-data as opposed to data-to-graph. Trying to go graph-to-data is where the jury-rig language, XML, comes from. The data never have been put into a permanent graph in the first place.
Think about it. If you have data points and you plot them into a graph, and the graph tells you that you need to refine the model from which the data is gathered, would you change the drawing of the graph, or change the collection of data points and cast a new graph? This is what is at issue. Bookkeeping uses minimal data by always working journal-to-ledger--data-points-to-graph. And this is why the bookkeeping department is having a terribly tough time with the data you are sending to them. There is a "once and only once" rule in data, just as their is in programming methods. Drawing data from a relational database makes it impossible to get Humpty-Dumpty together again.
A solution is to let the bookkeeping framework of rules, which have been refined in centuries of use, be the starting point for the work-flow control language--the algebra that resolves conflicts in the physical calculus-model. With the work-flow data in network form, and the pattern of working from journal to ledger firmly in place, the problem of data explosions and confused bookkeepers is completely resolved.
If others on this list express no further interest in double entry bookkeeping, and you would like to pursue this discussion, I will be happy to set up a bookkeeping list on Yahoo.
DanPalanza
BigPicture is mentioned on: ThreadView
