According to recommendations given here, F# modules should correspond to DDD bounded contexts, i.e. subdivisions of a business domain.

The bounded context I'm working on right now has 2 aggregates totalling a dozen of types, plus some rather complex functions/algorithms. If I follow the prescribed style, I end up with a 500+ LOC file, which IMO isn't very readable or navigatable, and it will only grow longer. Unfortunately, it seems F# modules can't be split across multiple files.

Other solutions I've attempted are :

  • One module per aggregate. Problem -- if I include the aggregate type in the module, I end up with an inelegant aggregate type name (e.g. MyAggregate.MyAggregate), especially when reused in non-F# .NET code.
  • One file with all the types of the bounded context under a particular namespace and another file containing the functions inside a module. Still not satisfying since in F# I can't give the same name to the module and namespace, and functions are not really organized inside the file.

    // This gives a "namespace and module named ... both occur in 2 parts of this assembly" error
    namespace MyProject.Domain.MyBC
    type MyType = 
        // ...
    namespace MyProject.Domain
    module MyBC = //...

I'm still looking for a solution that satisfies the following

  • Meaningful organization of code reflecting DDD concepts, so that code lookup feels easy and obvious
  • Some degree of compartmentalization, to prevent native access to other unrelated parts of the domain and avoid mistakes
  • Low cognitive load to explore a file (meaning no more than a few hundred lines of code per file)
  • Simple, non contrived usage from external non-F# .NET code

Have I missed the obvious way of doing it, or does the lack of partial modules + namespace/module collision just make them an awkward scope for DDD?

  • Perhaps, if that particular Bounded Context is so big, it would make sense to put it in a separate library..? Commented Nov 17, 2014 at 14:44
  • "Low cognitive load to explore a file" has absolutely no relation to the number of lines of code in a file. If you find it hard to read it's probably because you're intertwining pure code with side effects. About DDD first see stackoverflow.com/a/2181281/21239 Commented Nov 19, 2014 at 22:30
  • @MauricioScheffer "has absolutely no relation to the number of lines" -- do you have any link to research or something to back up that claim ? I have a visual memory so the longer the file, the more time it takes to find what I need. Plus it's a pretty common recommendation to keep code files reasonably short. Better a series of small labeled bags than a giant rag bag. Commented Nov 20, 2014 at 8:20
  • @MarkSeemann I don't see a 2-aggregate BC as particularly big. Plus that would mean a separate library with a single file in it containing a single module ? Commented Nov 20, 2014 at 8:23
  • @guillaume31 Do you have a link to research to back up the opposite? :) I just say it from my own experience. If you keep your code as pure as possible you usually don't need to scan an entire file to understand the code. You can focus on particular functions as the scope is smaller, and then you navigate to other functions as needed. Commented Nov 20, 2014 at 9:41

1 Answer 1


Having watched the section of the video you refer to, I don't see where Scott says a Bounded Context should correspond to a module. He just happens to chose a module to represent the Bounded Context in his example. There is absolutely no reason that a Bounded Context must correspond to a module.

If you feel your Bounded Context does not map well to a module, you are free to split it in whatever way you want. It can as many modules and types as you want, partitioned by namespace(s), assembly or whatever else floats your boat. All that matters is that the principles of a Bounded Context that you desire, are achieved.

With regards to file size and navigation, you could try Visual F# Power Tools Navigate To feature.

  • Absolutely, that's what I ended up doing. There's a trend though to consider Module = BC as a hard and fast rule -- I've heard it in other presentations and in conversations. Mark who commented on the question tweeted about it. Besides, I can understand why people take it at face value, because there's hardly a middle ground in this. It doesn't make much sense to say "a module is kind of a BC but you have to look at other modules to have a view of the complete BC". Better to have no rule at all then. Commented Jul 6, 2015 at 9:54
  • I somehow feel that this could all be solved if we had partial modules as there are partial classes in C#. I haven't really had the time to look into why this isn't possible in F# though, so it might not be a good idea. Commented Jul 6, 2015 at 9:58
  • I don't see it myself. A Bounded Context is a modelling concept. There should not be any "hard and fast" rules about how it is represented in a specific language (IMO). Will ping Mark and Scott to see if they can clarify. Commented Jul 6, 2015 at 10:20
  • 1
    I'm with @bentayloruk. The only hard and fast rule I follow is "there are no hard and fast rules". But what it's worth, here is what I do. First I generally keep function implementations away from the design, in a different module. That keeps the design part as small as possible and encourages abstraction. Note that I will often define function types in the design module as well if they are important part of the domain.
    – Grundoon
    Commented Jul 6, 2015 at 10:33
  • Second, as many others have suggested, if the design is getting too big, that's a clue that you might need to break it down into smaller sub-designs or sub-modules. In order to avoid issues with file order, and to encourage abstraction again, I might use generics (parametric polymorphism) to protect the upper layers from knowing anything about the specifics of the lower layers (see fsharpforfunandprofit.com/posts/removing-cyclic-dependencies). That trick means that the high-level design can come first in file-order.
    – Grundoon
    Commented Jul 6, 2015 at 10:39

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.