The way you're describing the changes as business operations is often employed with event sourcing, but of course you don't need to do event sourcing to follow the advice. The question then is why you want to use it - do you just intend to store an audit trail? Or do you just don't like the Object->DTO->DB approach and would prefer Changed object->[operations]->DB?
My experience with that concept is that while it sounds really nice and clean, in practice it's really hard to do in a meaningful way.
- Either you need a whole host of "edit buttons" (you'd arrange your ui slightly different and name things in another way, but the concept is the same) for all kinds of ways you might change data. For anything other than smallest object, you will not get that right. If you do this, then just store the (possibly compressed) sequence of operations.
- Or you need to guess what change was made, and that won't work if you want to map it to business operations. Was the address change due to misspelling or to the person moving?
Now, for me, this means that the most common interface type, namely "I want to change any of the values for this object", is a bad fit. The one thing you can extract is the diff of two objects. This is cumbersome in most OO languages, but can be done.
One suggestion if you go that path, would be to use the way svn or git does it. Keep track of what version the user started working with, check what version it is at the time of commit, and then compare these with the changed version. If the user wasn't up to date, you have multiple options; stop the commit, or allow the commit under certain conditions (needs to be chosen with domain expert).
Then take the minimal diff and use it; apply it in the database, store it in the audit log. (This is of course roughly what ORMs are doing on the original object.) You get an (in theory) replayable log, you don't have to come up with a large set of operations and you don't force users to use foreign user interfaces.
(Personally I've started to abandon "DDD techniques" for a more data/value oriented approach. The burdens and rigidity of "pure DDD techniques" weighs down much of the code, often with little gain other than the feeling of doing something right. I say "DDD techniques", DDD as an agnostic design idea is still good.)