Diretrizes de namespace e nome da classe

Estou tendo problemas para nomear minhas classes e serviços corretamente quando utils e outras classes de ajuda estão envolvidas.

Como você estruturaria o seguinte:

EventService.cs
EventServiceUtils.cs
EventServiceValidators.cs
EventServiceCoordinator.cs

etc ...

Eu tenho vários serviços com as mesmas necessidades do serviço acima. Um pensamento é separar tudo isso em um espaço para nome adequado, fazendo com que algo parecido com isto:

Services.EventService.EventService.cs //(the actual service)
Services.EventService.Validators.DateValidator.cs
Services.EventService.Validators.ParticipantValidator.cs
Services.EventService.Coordinators.ParticipantCoordinator.cs
Services.EventService.ExtensionMethods.Extensions.cs

e assim por diante. Todo espaço para nome é, obviamente, uma pasta separada. Mas isso não parece 100%, pois provavelmente há mais DateValidatorsem outros serviços, o que pode facilmente levar a uma referência indesejada.

E também Services.EventService.EventService.csinclui o nome da classe no espaço para nome, o que também não é bom. Você poderia usar Services.Event.EventService.cs, mas é claro que já existe uma entidade com esse nome.

Este é o modelo de domínio.

Eu acho que a maior coisa que você poderia fazer para melhorar seu espaço para nome aqui é remover Servicedo seu EventServiceespaço para nome. Eu também ajustaria os namespaces para serem mais assim:

Services.Events.EventService.cs //(the actual service)
Services.Events.EventExtensions.cs
Services.Events.ParticipantCoordinator.cs
Services.Validators.DateValidator.cs
Services.Validators.ParticipantValidator.cs

Ainda acho que isso poderia melhorar algumas coisas.

Eu gostava de namespaces, mas hoje em dia acho que menos é mais. Aninhar profundamente seus namespaces pode tornar seu código muito detalhado, e dividir as coisas em muito reduz sua capacidade de herança. No seu código, por exemplo, uma DateValidatorclasse pode ser facilmente usada em outro lugar, portanto, não deve ter muitos namespaces acima dela, já que outros serviços que não o EventService podem agora tirar proveito de uma classe DateValidator. O mesmo se aplica aos métodos de extensão. Não há tempo (que eu possa ver) em que você precise ver todos os seus métodos de extensão ao mesmo tempo; portanto, faz mais sentido agrupá-lo com o que está relacionado. Nesse caso, EventExtensionsprovavelmente está vinculado ao seu EventService, portanto, logicamente, eles devem ficar juntos na minha opinião.

Por que você não lê as Diretrizes Gerais de Nomenclatura e as Diretrizes de Nomeação de Namespace da Microsoft para seguir um padrão universal?

Eu acho que a fórmula <Company>.(<Product>|<Technology>)[.<Feature>][.<Subnamespace>]funciona bem.

O design adequado do espaço para nome considerará o design lógico e o físico.

Embora a lógica original dos espaços para nome tenha sido principalmente para impedir conflitos entre nomes de objetos e métodos, ela se tornou um elemento importante na arquitetura e no design gerais da solução. Você não apenas quer que sua hierarquia conceitual e design lógico façam sentido, como também provavelmente deseja que seu código seja empacotado de maneira organizada em bibliotecas bem projetadas e facilmente reutilizáveis ​​que possam ser facilmente agrupadas em outros projetos e produtos posteriormente. Esse talvez seja mais o resultado desejado de um bom projeto físico.

Veja o .NET Framework e como as unidades de funcionalidade relacionada são fornecidas a você em montagens de tamanho razoável. Você pode soltar uma referência e uma instrução de uso e, de repente, tem uma funcionalidade relevante disponível sem precisar arrastar qualquer número de pias de cozinha. Isso ocorre porque o design físico do .NET Framework - incluindo namespacing inteligente - empacotou código relacionado logicamente em unidades implantáveis ​​relacionadas fisicamente. Ao criar um excelente mapeamento entre namespaces e assemblies, os arquitetos e desenvolvedores da estrutura .NET da Microsoft tornaram seu trabalho significativamente mais fácil (é claro que alguns podem argumentar o contrário, mas estou muito feliz com o que eles fizeram).

O namespace em C # é bastante arbitrário, na verdade. Você pode colocar espaços para nome nos locais mais estranhos, em montagens muito distantes umas das outras. Qualquer disciplina útil nessa área é realmente sua contribuição pessoal para um produto de software bem organizado. Não ousaria aconselhá-lo exatamente sobre o que fazer em cada caso. O que espero conseguir, nesta resposta, é fazer com que você pense sobre design físico e design lógico ao definir seus namespaces. Quanto mais você mantiver as coisas logicamente relacionadas e agrupar de maneira implementável (fisicamente), mais fácil será mais tarde, tanto para você quanto para outras pessoas que possam precisar lidar com seu código algum dia.

Portanto, pense em como o seu código será empacotado em montagens e componentes quando você resolver seus problemas de espaço para nome!