O que e quanto código de domínio deve ser colocado em um módulo F #

5

De acordo com as recomendações fornecidas aqui , os módulos F # devem corresponder aos contextos DDD, ou seja, subdivisões de um domínio de negócio. / p>

O contexto limitado em que estou trabalhando agora tem 2 agregados, totalizando uma dúzia de tipos, além de algumas funções / algoritmos bastante complexos. Se eu seguir o estilo prescrito, acabo com um arquivo de 500 + LOC, que não é muito legível ou navegável, e só vai crescer mais. Infelizmente, parece que os módulos F # não podem ser divididos em vários arquivos .

Outras soluções que tentei são:

  • Um módulo por agregado. Problema - se eu incluir o tipo agregado no módulo, acabo com um nome de tipo agregado deselegante (por exemplo, MyAggregate.MyAggregate ), especialmente quando reutilizado em código não-F # .NET.
  • Um arquivo com todos os tipos de contexto delimitado sob um espaço de nomes específico e outro arquivo contendo as funções dentro de um módulo. Ainda não é satisfatório, pois em F # não posso dar o mesmo nome ao módulo e ao namespace, e as funções não são realmente organizadas dentro do arquivo.

    // 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 = //...
    

Ainda estou procurando uma solução que satisfaça o seguinte

  • Organização significativa do código que reflete os conceitos do DDD, para que a pesquisa de código pareça fácil e óbvia
  • Algum grau de compartimentalização, para impedir o acesso nativo a outras partes não relacionadas do domínio e evitar erros
  • Baixa carga cognitiva para explorar um arquivo (ou seja, não mais do que algumas centenas de linhas de código por arquivo)
  • Uso simples, não planejado, de código externo não-F # .NET

Eu perdi a maneira óbvia de fazê-lo, ou a falta de módulos parciais + colisão de namespace / módulo apenas os torna um escopo inadequado para o DDD?

    
por guillaume31 17.11.2014 / 13:26
fonte

1 resposta

2

Após assistir à seção do vídeo a que você se refere, não vejo onde Scott diz que um contexto limitado deve corresponder a um módulo. Ele simplesmente escolheu um módulo para representar o contexto limitado em seu exemplo . Não há absolutamente nenhuma razão para que um Contexto Limitado tenha que corresponder a um módulo.

Se você sentir que o seu Contexto Limitado não mapeia bem para um módulo, você está livre para dividi-lo da maneira que quiser. Pode quantos módulos e tipos desejar, particionado por namespace (s), assembly ou qualquer outra coisa que flutue seu barco. Tudo o que importa é que os princípios de um Contexto Limitado que você deseja sejam alcançados.

Com relação ao tamanho do arquivo e à navegação, você pode tentar o recurso Visual F # Ferramentas de Energia Navegar para .

    
por 06.07.2015 / 11:12
fonte