6

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?

Improve this question
14
  • Perhaps, if that particular Bounded Context is so big, it would make sense to put it in a separate library..?
    – Mark Seemann
    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
    – Mauricio Scheffer
    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.
    – guillaume31
    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 ?
    – guillaume31
    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.
    – Mauricio Scheffer
    Commented Nov 20, 2014 at 9:41

1 Answer 1

Reset to default
3

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.

Improve this answer
8
  • 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
    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.
    – guillaume31
    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.
    – bentayloruk
    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.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.