Estrutura do projeto

[HClausing]

Atualmente, o projeto consiste na distribuição de uma única DLL e Pacote Nuget, contendo todas as escriturações que já possuem ou irão oferecer suporte, além de oferecer os serviços de consumo de API's e/ou WebServices, que é o caso da EFD-REINF.

Por meio desta Issue, propõe-se discutir se esta estrutura oferece o melhor caminho para distribuição/consumo da biblioteca.

Inicialmente, podemos enumerar três possibilidades:

A: Modelo Atual, separado apenas por namespaces

\Schemas\Escrituracao\Classes
\Services\Escrituracao\Classes

Prós: O pacote é autossuficiente e de fácil implantação nos mais diversos projetos.

Contras: Tamanho maior do assembly final para o pacote. Em soluções usando .NET 7+, com assembly trimming, ao menos em teoria, não se aplicaria este revés.

B: Separação em Schemas e Services em pacotes separados

Schemas.dll:
\Escrituracao\Classes
Services.dll:
\Escrituracao\Classes

Prós: Reduz a carga de dependências em aplicações que teoricamente não precisariam consumir os serviços, com por exemplo soluções de compliance tributário, análise e validação dos dados de arquivos/eventos já gerados.

Contras: Bem semelhante ao item A, uma vez que a grande maioria das classes ainda persistiria no assembly Schema.

C: Separação por Obrigação Acessória (schema) em múltiplos pacotes, contendo também a implementação de seus serviços, quando aplicáveis

Core.dll: (utilitários em geral)
Ecd.dll
EfdIcmsIpi.dll
Nfe.dll
(e muitas outras...)

Prós: Talvez seja o modelo mais democrático possível. Soluções mais voltadas ao varejo poderiam referenciar apenas as dependências relativas à emissão de documentos fiscais, enquanto soluções de compliance tributário poderiam ignorar schemas que não estão voltados ao projeto SPED.

Contras: Uma solução contábil/fiscal completa faria referência a praticamente todas os pacotes, causando um grande número de pacotes instalados.