BusinessTransaction''''''s provide a focus during transaction processing for complicated events, processing activities, and policy decisions. The sequence of transactions forms the historical record of the organization. In theory, transactions last forever as part of the permanent record of the organization. Even if they don't get lost, they can't be stored in the same way forever. Eventually they have to be moved to some form of less expensive storage. Much of the data that you need when you are processing a transaction, such as which steps in the processing have been performed, are not needed for posterity. On the other hand, you may need to keep certain information in an archive that would not necessarily be associated with a transaction during processing, such as the effect the transaction had on the customer relationship (i.e., before and after values of key items of information).

'''Therefore:''' use different representations of transactions during processing than for archival purposes. Don't archive transactions until you have finished all processing related to the business event, including rerunning it and generating management information.
-----
Inspired by a note from LarryBest.
----
I have been thinking along similar lines. I've modelled each completed transaction as a ValueObject (because they can't/shouldn't change state once they are added to the history log). This reveals another aspect of the ValueObject/ReferenceObject discussion - you can define a pair of companion classes - one that allows change and one that represents the same information but can't be changed (i.e. it is a ValueObject). The ReferenceObject class could be designed with a factory method that produces a frozen "snapshot" of its current state and the ValueObject
class can be designed with a factory method that makes a changeable representation of the state of the current ValueObject.

For example consider java.util.Date - it's a ReferenceObject (i.e. you can change its state). There's no reason why you can't implement a class that is a Date ValueObject and it could have a factory method for creating a changeable version of a date value (i.e. an instance of java.util.date) set up with a similar initial state.

--

The first time I saw the distinction between transaction processing and Analytics was in Tapscott's book ''Paradigm Shift'', which is worth the read despite the title. From memory, unfortunately as I can't find the paper, RobinBloor divides IT systems into TransactionProcessing, Analytics, and GroupWare categories:

	* TransactionProcessing implements the fairly disciplined core processes of a business.
	* Analytics collects, collates and delivers aggregate, summary, directional and so on information to influence and inform.
	* GroupWare (if I have his chosen term right) supports knowledge work, so has some elements of workflow, shared resources, and productivity applications.

Tapscott and Bloor work typically with IT strategy, and architectures for whole systems or whole enterprises vs. at the code or design level. Yet they seem to have hit on about the same distinction you make above and for the same reason - these things behave differently. I think it's a valid distinction. -- JamesBullock