2. Simplicidade

Também é propósito desse projeto ser simples. Usar apenas o que agrega valor para a solução e que seja justificadamente necessário. Naturalmente podem haver pontos que se desviam desse propósito, mas assim que percebidos serão refatorados.

Faço aqui uma referência aos princípios KISS e YAGNI.

Não tenho objetivo de criar uma estrutura pomposa, que abusa de DLLs e Namespaces para simplesmente fazer a Solution parecer mais complexa, luxuosa, mais elegante ou mais importante do que realmente é. Se fisesse, certamente depois de um tempo isso se tornaria ruído nos projetos, desviaria a atenção do problema ou tornaria a manutenção difícil, cansativa ou desmotivante até o ponto onde esse projeto desse projeto se tornar obsoleto ou inviável. Mas é importante não confundir isso com super classes que abraçam mais responsabilidade do que comportam.

Note que a Solution inicial é composta por dois projetos, o Core e o Desktop. Quando se modela um Domínio, a neutralidade tecnológica é fundamental, por isso, um Domínio não deve ter ligações externas com Infraestrutura ou Interface de Usuário por exemplo. Assim, alterações de tecnologia não influenciam nas regras de negócio. No entanto, isolar o Domain em uma DLL à parte não é a única forma de se fazer. Neste projeto, opto por isolar a Interface e manter uma tríade (Domain, Infra e Services) em uma DLL separada, afinal, nesse projeto em específico o Domínio não é grande o suficiente e a probabilidade de mudanças na Infraestrutura é muito baixa. Com isso, o DomainModel, Infrastructure, Services e CrossCutting ficarão na mesma DLL, que chamarei de Core. Mas perceba que, não há nenhuma classe do Namespace DomainModel fazendo using de Namespaces como Infrastructure ou Services. Nosso Domínio está isolado e todo o isolamento acontecem normalmente através de modificadores de acesso private e internal.