In base alle raccomandazioni fornite qui , i moduli F # devono corrispondere ai contesti delimitati da DDD, ovvero suddivisioni di un dominio aziendale.
Il contesto limitato su cui sto lavorando ora ha 2 aggregati per una dozzina di tipi, più alcune funzioni / algoritmi piuttosto complessi. Se seguo lo stile prescritto, finisco con un file LOC 500+, che IMO non è molto leggibile o navigabile, e crescerà solo di più. Sfortunatamente, sembra che i moduli F # non possano essere suddivisi su più file .
Altre soluzioni che ho provato sono:
- Un modulo per aggregato. Problema: se includo il tipo aggregato nel modulo, ottengo un nome di tipo aggregato inelegante (ad esempio
MyAggregate.MyAggregate), specialmente se riutilizzato nel codice non F # .NET. -
Un file con tutti i tipi di contesto limitato in un particolare spazio dei nomi e un altro file contenente le funzioni all'interno di un modulo. Ancora non soddisfacente dato che in F # non posso dare lo stesso nome al modulo e al namespace, e le funzioni non sono realmente organizzate all'interno del 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 = //...
Sto ancora cercando una soluzione che soddisfi i seguenti
- Organizzazione significativa del codice che riflette i concetti DDD, in modo che la ricerca del codice sia facile e ovvia
- Un certo grado di compartimentalizzazione, per impedire l'accesso nativo ad altre parti del dominio non correlate ed evitare errori
- Basso carico cognitivo per esplorare un file (ovvero non più di poche centinaia di righe di codice per file)
- Utilizzo semplice e non forzato da codice esterno non F # .NET
Ho perso l'ovvio modo di farlo, o la mancanza di moduli parziali + collisione namespace / modulo li rende semplicemente uno scope scomodo per DDD?