8

I'm learning DDD and yet I have more questions than answers.

Let's consider a model of a directory containing enormous number of files.
Here is how I see it:

Directory is an Aggregate root.
This entity should have the validation logic of checking file name uniqueness when it is added or just renamed. And File entity contains the 'SetName' logic, notifying Directory via Domain Event about name changes.
But how should Directory then work?
It is not always possible to load all files into memory. Should in this case Files repository have adhoc logic for checking name uniqueness? I suppose it is a viable decision.
However, what if some files have been already added or renamed withing current not yet commited transaction? (nothing prohibits that. Transaction boundaries are set externally in relation to business logic). Probably repository should take into account both in-memory and persisted states (merging these states can be nontrivial task.)

So, when aggregate root with all its children fits in memory - everything is fine. And as soon as you can not materialize all entities there are troubles.

I'd like to know what are the approaches for such situations. May be there is no problem at all and it is just because of my misunderstanding of the subject.

  • 1
    What makes you think you have to load all files and their content and not just "FileInfo"? – Euphoric Jul 16 '14 at 13:46
  • @Euphoric. Well, sometimes even that is not possible. Anyway there is another problem. How to provide consistency of FileInfo and corresponding File entities changed inside current transaction? Probably CQRS addresses this question...haven't looked at it yet. – Pavel Voronin Jul 16 '14 at 13:59
  • 1
    It's useful to understand that DDD isn't a programming technique, but rather a design technique. Too many folks treat it like a coding methodology. Terms like "aggregate root" aggravate the problem, because they give the impression of technical weight, when in fact they don't actually speak much to programming techniques. Programming techniques do not change much in DDD; while DDD does inform your code and architecture, you still have code and architecture separate from it. – Robert Harvey Jul 16 '14 at 16:55
  • @RobertHarvey It seems to me that DDD requires more complex programming techniques. At least when it comes to corner cases. I treat DDD mostly as a way to separate (and localize) business logic from inevitable infrastructure code which works implicitly behind the scenes. For me DDD=good OOD + implicit infrastructure. Most of the questions I have concerning DDD relate to last part. – Pavel Voronin Jul 17 '14 at 5:26
  • 2
    Why do you say: "Transaction boundaries are set externally in relation to business logic" ? The duty of aggregate root is to maintain a transactional boundary. Also you don't have to load the contents of the files. You can just load meta data. – Esben Skov Pedersen Sep 14 '14 at 13:43
18

My answer is biased with Vaughn Vernon's Implementing Domain Driven Design great book (a must read)

1. Favor small aggregates.

If I'm to model your domain, I would model a Directory as an aggregate and File as another aggregate.

2. Reference aggregates by ids.

Therefore Directory will have a collection of FileId value objects.

3. Use factories to create aggregates.

For a simple case a factory method may be enough Directory.addFile(FileName fileName). However, for more complex cases I would use a domain factory.
The domain factory could validate that the fileName is unique using a FileRepository and a UniquefileNameValidator infrastructure service.

Why model File as a separate aggregate?

Because Directories aren't made of Files. a File is associated with a certain Directory. Also, think of a directory that has thousands of files. Loading all these objects into memory each time a directory is fetched is a performance killer.

Model your aggregates according to your use cases. If you know that there will never be more than 2-3 files in a directory then you can model them all as a single aggregate, but in my experience business rules change all the time and it pays if your model was flexible enough to accommodate the changes.

Obligatory read Effective Aggregate Design by Vaughn Vernon

  • 2
    Note that indeed real directory implementations are usually implemented like this (separate aggregates, referenced by their ids). For example, "Files" are simply referenced from their directory by their inode on Unix systems. – Alexander Langer Oct 1 '14 at 6:05
  • 1
    I have finally read the recommended book. Great book, thank you. Nonetheless, it is still not completely clear. Only one File with given Name can exist in Directory, i.e. Directory has the invariant: Name uniqueness. At least it is important for the Directory, but not for the File. Actually @AlexanderLanger is right: 'File' can be referenced by many 'Folders'. And the Name is probably the property of this reference rather than of the File itself. Ok. Then renaming functionality belongs to the Directory, but again it is not a good idea to store thousands of referenced identities. – Pavel Voronin Oct 28 '15 at 17:22
  • And even if we did, we would need to make a check against names. From here it looks reasonable to create a method in folders repository: bool ContainsFileOfName(int folderId, string fileName). After that 'Rename' method signature can be the following: void Rename(int fileId, string newName) where inside some IFolderService (which wraps repository) is resolved and asked whether such name exists. – Pavel Voronin Oct 28 '15 at 17:37
1

This this is not a DDD question per se. The main question here is about synchronization context (which is here an aggregate root).

Back on topic: Directory shall block on some synchronization object of file names and perform a check whether the given file name is allowed which is O(n) in the worst case.

1

Although some may say that try to change your design, there is always a need where an AR will have a large list of simple objects. And to store them in memory is not the best thing to do from a performance perspective, however, all you need to do in such cases is to preserve the transaction boundaries. A simple solution is the following:

  1. Keep the AR of the folder simple, and put a version column.
  2. Have each file (let say row) reference the aggregate root, in other words, to keep the id of the folder.
  3. Always perform the changes of the files, such as rename, add, remove, via the AR. In other words, if you want to add a file, load the AR, and use a method in AR to do the change. Assuming you are using a repository pattern, the addFile() will create a new file, change the version of the folder. Save those as a UoW. If someone else has changed the AR you will get an error due to Version Column (the AR version).
  4. Any change to the file itself, like Editing the file or renaming it, should be done via the AR. So the version is kept in the AR. This means essentially that there are no other execution paths in your code that change the file, except the owning AR.

Some restrictions:

  1. The file should belong to only one AR. If this is not the case, then model the relation of Folder -> File as containment and not the file itself.
  2. You cannot move one file from one folder to the other, unless you do this change in a UoW, in other words in the same transaction. This is a special case, as you should send one request that will end up in two commands, so both ARs will be changed, therefore two new versions for each, and probably two events (file removed, file added) and this is a bit tricky because you should maintain the event orders for the two ARs which sometimes is not easy.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.