tell-don't-ask vs. no external dependencies on domain objects

gistfile1.cs

// tell don't ask means I might do something like this
var folder = new Folder("foo");
folder.Delete();

// but for that to work the folder class needs to depend on a file IO service (to do the deleting).

// the alternative is procedural

public class FolderService
{
  public FolderService(IFileSystem fileSystem) {...}

  public void Bar()
  {
    var folder = new Folder("foo");
    fileSystem.Delete(folder.Path);     // here is the tell-dont-ask violation
  }
}

// what is the right way to do this?

If you look at posts e.g. from Udi Dahan about Domain Events, the Domain objects do have a possibility to raise events (messages, whatever). It also lends itself well to a certain kind of blackbox testing. If you use some kind of event aggregator (I prefer to think of it as Bus) in your test you can assert whether certain messages/events have been generated by the parts of the domain under test.

FWIW, I've build a number of large systems using Event Sourcing - I'm giving a talk next week as it happens - and I would never go back to using anything else. Testing is a breeze.

Thanks everyone. Udi talks about Domain Events at http://www.udidahan.com/2009/06/14/domain-events-salvation/. Domain Events appear to be an elegant partial solution to the original problem. I say partial because an external dependency is still required.