3

I'm designing an editor as a desktop application that opens, saves and saves as documents from files, something very common in fact.
I already have Bounded Contexts for my business rules.

Naively, I want to put the paths of the files used to re-hydrate entities as their identities and implement the repositories with file access and management.
But I have the feeling that it's not the right way to manage the file aspect in my application.

So, do you think it may be interesting to design a Bounded Context dedicated to file management?
Do you have examples of such applications mixing DDD and file management?

Most examples show databases access through repositories and I was not able to find anything about that so far.

Improve this question
5
  • In DDD, a subdomain in the problem space is mapped to a bounded context in the solution space. A bounded context is an area of the application that requires its own ubiquitous language and its own architecture. (quoted from microsoftpressstore.com) Did you mean to ask if it makes sense to apply DDD Tactical Patterns when building a file management application?
    – Rik D
    Commented Dec 3, 2020 at 15:52
  • The quote seems to indicate that a Bounded Context specific to file management may makes sense. I don't know much about DDD Tactical Patterns and I'm having a deep look at it, so I can't answer your question yet! Thanks!
    – Loïc Morvan
    Commented Dec 3, 2020 at 16:23
  • As far as I understood, Tactical Patterns are Building Blocks (Entities, Value Objects, Services, etc...), right? To answer your question: in a sense yes, I'm wondering if we should model the files that are manipulated by the user through the application using these Building Blocks, and more important, if we should tie together these models into a separated Bounded Context dedicated to file manipulation and clearly separated from the other Bounded Contexts that represent the "real" business - that is to say not the management of files.
    – Loïc Morvan
    Commented Dec 3, 2020 at 16:52
  • Hi Loic, I'm curious: what does "define a bounded context" mean to you, concretely?
    – TheHowlingHoaschd
    Commented Dec 4, 2020 at 10:11
  • Hi! I mean design a BC with its own Entities, Aggregates, VOs in order to place all that is related to files in it and avoid mixing file-related concepts into the other BCs (for example a property "has changed", a property "file path", maybe also a property "content" as a byte stream?)
    – Loïc Morvan
    Commented Dec 4, 2020 at 15:54

2 Answers 2

Reset to default
2

As I understand it file management is not part of your business domain so a dedicated bounded context does not make sense from my opinion.

I can somehow understand though that you don't feel comfortable using a file path as identifier for your aggregates as primitive string type. So I suggest to create a value object, e.g. DocumentId which encapsulates this identify aspect and abstracts it away from the client code working with the domain model. The rest of the repository implementation works the same as if you would have stored the content in a database. Use a repository interface in the domain layer and the repository implementation is in the infrastructure layer.

Improve this answer
4
  • Indeed, this removes the need for using the file path as the identity. However, I'm anticipating the day when we don't want to manage files anymore, in favor of cloud resources for instance. So I'm wondering if can get rid of any aspect of the file in our BCs.
    – Loïc Morvan
    Commented Dec 4, 2020 at 16:13
  • I guess the entities known to your business are some kind of documents, not files. I rephrased the value object to DocumentId. When you hydrate your document aggregates from the data source (here a filesystem) you do not need to know anything about files. I was assuming that anyway. So your aggregate would be something like Document maintained in the document repository. Only the repository implementation knows about files. When you want to switch to another data source you can simply change the concrete repo implementation leaving the repo interface including the DocumentId value object as is
    – Andreas Hütter
    Commented Dec 4, 2020 at 16:45
  • If entities are considered as document, then the DocumentId would directly be the identity of the entity, isn't it? In practice, your solution may be totally useful. However, I have the feeling that adding a DocumentId property is not strictly DDD-compliant.
    – Loïc Morvan
    Commented Dec 7, 2020 at 8:22
  • DocumentId is just a proposal for the name. The important thing is, that from how understand from your problem description, that this is really about documents existing in the problem domain of your business. Like a word document is known to the users of Microsoft Word. So I guess there is also some kind of identification of a document which the user of your desktop application is opening and saving to. So I do not understand why such an identification is not DDD-compliant. The value object can also be DocumentName or whatever makes sense in your domain.
    – Andreas Hütter
    Commented Dec 10, 2020 at 19:21
0

From the book, I understood a bounded context as an area of development, that is integrated enough, so people can agree on the concepts represented by names. Splits seem to occur between teams, that work on separate aspects of a problem without heavy communication and coordination. (this question also discusses this)

It doesn't seem like the problem you describe needs to be handled across multiple teams. You could just move file management into a separate module in the fashion of a Generic Subdomain.

Improve this answer
1
  • The idea behind my question (and I should have written it...) is how to keep the BCs clearly away from the infrastructure details, in case I want to replace files with some Cloud resources later without having to change anything from the existing BCs.
    – Loïc Morvan
    Commented Dec 4, 2020 at 16:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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