You Cloned the Aggregate. Why Is Your Read-Only Operation Still Changing State?

In the article, the author presents a common problem when trying to preview the outcome of a domain operation without actually modifying the original state. The example used is a `Trip` aggregate, which contains a list of stops and the current progress of the trip. The scenario is as follows:

1. A `Trip` object has its own state, including stops and progress.

2. There is a domain service, `AdvanceRoute`, that simulates the progression of the trip by moving it forward and updating the trip's progress and the driver's compliance ledger.

The author mentions a first implementation where a clone of the `Trip` is created, and the `AdvanceRoute` method is called on the cloned object. The author suggests that this should prevent any changes to the original `Trip`, but this is not the case.

The problem arises because the `AdvanceRoute` method is not only modifying the `Trip` object but also the `DriverComplianceLedger` object, which is not a part of the `Trip` object graph. The author points out that the `Clone()` method of the `Trip` creates a deep copy of the `Trip`, copying all relevant state, but it does not clone the `DriverComplianceLedger` object.

The critical distinction the author makes is between the object graph (what belongs to the `Trip` aggregate) and the mutation boundary (what the operation can change). While a deep clone of the `Trip` correctly isolates the object graph, it does not isolate the mutation boundary. The domain logic changes the `DriverComplianceLedger`, which was not cloned, thus modifying the real production state.

In summary, the problem is that cloning an object does not necessarily prevent an operation from modifying state outside of its intended scope if that state is not part of the cloned object graph.