Vou procurar listar aqui no blog algumas das Rule of Thumbs do DDD aos poucos. Hoje vou comecar falando sobre Atomicidade dos Aggregates e Bounded Contexts.Vaughn Vernon diz em seu livro "Implementing DDD": "A properly designed Aggregate is one that can be modified in any way required by the business with its invariants completely consistent within a single transaction. And a properly designed Bounded Context modifies only one Aggregate instance per transaction in all cases. (...) Limiting modification to one Aggregate instance per transaction may sound overly strict. However, it is a rule of thumb and should be the goal in most cases. It addresses the very reason to use Aggregates." O que aprendemos aqui de pratico? Que...[1] Se uma agregacao precisa sofrer duas operacoes para manter consistencia, entao ela nao esta devidamente construida.Por exemplo:venda.AdicionarItem(novoItem);venda.ValorTotal += novoItem.SubTotal;No codigo acima, se ao adicionar o item o valor total nao for computado internamente, nossa agregacao entrara num estado inconsistente.[2] Embora nao seja o contexto, podemos concluir pela mesma logica que um Application Service deve realizar uma unica operacao por Bounded Context, seja diretamente em uma agregacao ou atraves de uma unica chamada de servico. Num determinado momento durante o desenvolvimento do projeto no qual estou alocado no momento, eu quis aproveitar para depurar um pacote do NuGet que instalei no meu projeto, pacote este ao qual fui eu mesmo quem o criou. Eu quis aproveitar o cenario que ja estava instaurado no momento da depuracao do projeto para tentar encontrar um possivel bug no componente do pacote. Porem isto nao foi possivel pois o pacote distribuido e referenciado continha apenas o assembly (.dll), e para a realizacao da depuracao faz-se necessario a existencia do arquivo de simbolos (.pdb).Apesar da possibilidade de atender a este problema com uma solucao em particular (e.g. copiando o .pdb manualmente), eu aproveitei para tentar encontrar uma solucao madura para casos como este. O primeiro pensamento foi em convencionar a distribuicao dos arquivos .pdb's dentro dos respectivos pacotes do NuGet, mas isso nao me pareceu razoavel como uma solucao definitiva, pois assim os arquivos de simbolos tambem seriam disponibilizados no ambiente de producao, o que pra muitos e considerado inseguro, pois em casos especificos algumas informacoes valiosas sobre a construcao da aplicacao poderiam ser exploradas indevidamente.Assim, depois de fazer uma pesquisa sobre o assunto, conclui que a alternativa seria configurar um Symbol Server Privado para ficar disponivel no ambiente de desenvolvimento. Este Server fica entao responsavel pelo armazenamento dos arquivos de simbolos, e o depurador fica configurado para consulta-lo sempre que precisar depurar um assembly.Apesar da solucao ser simples, a minha pesquisa nao o foi. Por que? Porque, de um lado, eu encontrei materiais explicando como configurar um Symbol Server para ser consumido pelo Visual Studio (WinDbg); do outro, encontrei como gerar Symbol Packages do NuGet para ser publicados no SymbolSource.org, mas nao encontrei como utilizar um Symbol Package do NuGet num Symbol Server privado. Minha duvida era: o depurador faria o download do arquivo .symbol.nupkg e saberia extrair o .pdb?Uma vez que nao consegui encontrar em uma unica pagina