5

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
    
    //File1.fs
    
    namespace MyProject.Domain.MyBC
    
    type MyType = 
        // ...
    
    //File2.fs
    
    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..? – Mark Seemann Nov 17 '14 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 – Mauricio Scheffer Nov 19 '14 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. – guillaume31 Nov 20 '14 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 ? – guillaume31 Nov 20 '14 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. – Mauricio Scheffer Nov 20 '14 at 9:41
2

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. – guillaume31 Jul 6 '15 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. – guillaume31 Jul 6 '15 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. – bentayloruk Jul 6 '15 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 Jul 6 '15 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 Jul 6 '15 at 10:39

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.