¶ Visão Estratégica e Pipeline de Desenvolvimento - SSAG3.0Core
¶ 1. Objetivo do Documento
Este documento descreve a estratégia híbrida para o desenvolvimento do SSAG3.0Core e SSAG3.0ERP, conciliando geração automática e validação de estruturas com personalização manual. O objetivo é garantir:
- Eficiência no desenvolvimento: Acelerando a criação de classes e componentes.
- Conformidade com padrões: Validando que as personalizações sigam as regras e nomenclaturas do Core.
- Flexibilidade: Permitindo customizações específicas para clientes ou grupos de usuários.
- Escalabilidade e performance: Priorizando o desempenho e a capacidade de adaptação futura.
¶ Diagrama
¶ 2. Estratégia Híbrida: Desenvolvimento e Customização
¶ 2.1. Geração Automática
-
Pipeline de Geração:
- A partir do Core (ex.: tabelas, campos e regras cadastradas), serão gerados automaticamente:
- Classes.
- Repositórios.
- Configurações iniciais (mapeamento EF Core, DTOs).
- Estrutura de menus e interfaces básicas.
- A partir do Core (ex.: tabelas, campos e regras cadastradas), serão gerados automaticamente:
-
Ferramentas Envolvidas:
- Geradores automáticos baseados no Core para criação de arquivos
.cs. - Utilização de templates padronizados para garantir consistência.
- Geradores automáticos baseados no Core para criação de arquivos
¶ 2.2. Customização Manual
-
Possibilidades de Customização:
- Módulos: Personalização de funcionalidades e regras.
- Tabelas e Campos: Adição ou alteração de elementos.
- Menus e Interfaces: Configurações específicas para clientes, grupos de empresas ou perfis de usuários.
-
Validação das Customizações:
- O Core fornecerá ferramentas de validação para garantir conformidade com as regras:
- Padrões de nomenclatura.
- Conexão com as entidades do domínio.
- Integridade de regras de negócio.
- O Core fornecerá ferramentas de validação para garantir conformidade com as regras:
¶ 3. Arquitetura Proposta
¶ 3.1. Estrutura do SSAG3.0Core
- Camada de Domínio: Contém as entidades principais, repositórios e regras de negócio.
- Camada de Aplicação: Gerencia os casos de uso e orquestra chamadas ao domínio e à infraestrutura.
- Camada de Infraestrutura: Inclui persistência, logs e integrações externas.
- UI: Interface com suporte ao Blazor Server.
¶ 3.2. Integração com SSAG3.0ERP
-
Base do ERP:
- O Core será a base para o desenvolvimento do ERP.
- As funcionalidades do ERP serão carregadas a partir do Core (dinamicamente ou através de arquivos gerados).
-
Fluxo de Dados:
- Core: Gera a estrutura padrão.
- ERP: Estende ou customiza as funcionalidades para atender às necessidades específicas do cliente.
¶ 4. Benefícios da Estratégia Híbrida
- Performance: Reduz o tempo de desenvolvimento com geração automática.
- Escalabilidade: Permite que múltiplos clientes compartilhem a mesma base, com customizações específicas.
- Conformidade: Garante que todas as personalizações sigam os padrões estabelecidos.
- Adaptabilidade: Suporta mudanças e evolução tecnológica com menor impacto no desenvolvimento.
¶ 5. Pipeline de Desenvolvimento
¶ 5.1. Fases do Pipeline
-
Core Development:
- Configuração inicial do Core.
- Implementação de tabelas, campos, menus e validações.
- Criação dos módulos internos.
-
Gerador Automático:
- Desenvolvimento de ferramentas para gerar classes e arquivos com base no Core.
-
Customização no ERP:
- Implementação de extensões baseadas no Core.
- Personalizações específicas para cada cliente.
¶ 5.2. Automação no Pipeline
- Scripts para geração de classes e arquivos
.cs. - Validações automáticas integradas ao pipeline CI/CD:
- Garantir a integridade do Core antes do deploy.
¶ 6. Aprovação e Colaboração
Este documento está aberto para revisão e discussão. Caso haja ajustes necessários, a equipe pode utilizar o espaço de comentários ou criar tickets específicos no Jira.
¶ Quadro Comparativo: Arquiteturas Avaliadas
| Critério | Core Dinâmico (Runtime) | Geração Estática de Arquivos | Híbrida (Proposta) |
|---|---|---|---|
| Performance | Pode ter impacto em tempo de execução. | Melhor performance em runtime. | Combina performance estática com flexibilidade dinâmica. |
| Escalabilidade | Boa para ambientes altamente dinâmicos. | Limitada a alterações em design-time. | Altamente escalável com ajustes controlados. |
| Flexibilidade | Total flexibilidade para alterações. | Dependente de novas compilações. | Flexibilidade controlada, com regras pré-definidas. |
| Manutenibilidade | Pode ser complexa devido à carga dinâmica. | Simples, mas exige processos manuais. | Gerencia a complexidade com geração inicial e validação contínua. |
| Adaptação ao Cliente | Altamente customizável, mas mais lento. | Exige recompilação para cada cliente. | Permite customização com bases padrão e validação do Core. |
| Complexidade Técnica | Alta (demanda infraestrutura robusta). | Moderada (processo mais direto). | Média (infraestrutura simplificada com geração e validação). |
| Validação de Regras | Validação em tempo de execução. | Validação em design-time. | Validação híbrida em tempo de execução e geração. |
| Curva de Aprendizado | Maior, exige maior domínio técnico. | Menor, desenvolvedores seguem padrões. | Balanceada, com processos e ferramentas definidos. |
¶ Por que escolher a abordagem híbrida?
- Performance e Flexibilidade: Combina o melhor de ambas as abordagens, oferecendo performance para operações padrão e flexibilidade controlada para customizações.
- Escalabilidade: Suporta crescimento contínuo sem comprometer a estabilidade do sistema.
- Manutenibilidade e Simplicidade: Reduz a complexidade ao permitir que desenvolvedores trabalhem com padrões gerados e validados pelo Core.
- Adaptação: Alinha-se ao objetivo de permitir customizações específicas para clientes ou grupos, sem sacrificar as boas práticas e a consistência do sistema.
¶ Recomendações
- Mantenha este quadro acessível no Wiki e em apresentações estratégicas para consultas futuras.
- Use-o em treinamentos e reuniões para explicar a escolha da arquitetura à equipe técnica e stakeholders.
Conclusão: A abordagem híbrida representa o equilíbrio entre flexibilidade, performance e controle, alinhando-se perfeitamente aos objetivos estratégicos do SSAG3.0.
¶ Quadro de Aprovações - Visão Estratégica e Pipeline de Desenvolvimento
| Nome do Sócio | Cargo | Aprovação | Data | Comentários |
|---|---|---|---|---|
| Márcio de Matos Costa | Gestor do Projeto | [X] Sim / [ ] Não | 24/11/2024 | |
| Renato Vilar | Sócio/Back End | [_] Sim / [ ] Não | DD/MM/AAAA | |
| Jhon Araújo | Frontend Líder | [X] Sim / [ ] Não | 24/11/2024 |
¶ Instruções
- Cada sócio deve revisar o documento detalhado da visão estratégica e pipeline de desenvolvimento.
- Marque a aprovação como
[x] Simou[x] Não. - Caso necessário, adicione comentários para justificar a decisão.
Após preenchimento, envie o quadro atualizado para o Gestor do Projeto para registro no Wiki.
¶ Estrutura de Bancos de Dados do SSAG3.0
¶ Diagrama
¶ Ambiente de Desenvolvimento
¶ 1. SDBCore
- Descrição: Banco de dados central para definições, nomenclaturas e regras gerais.
- Uso: Exclusivo para gestores do projeto e equipe do núcleo.
- Acesso: Altamente restrito.
- Objetivo: Controlar as bases do sistema (tabelas, dicionários, consultas padrão).
¶ 2. SDBERP
- Descrição: Banco de dados dos módulos do ERP em desenvolvimento.
- Uso: Exclusivo para gestores e desenvolvedores.
- Acesso: Restrito.
- Objetivo: Permitir desenvolvimento de módulos do ERP.
¶ 3. SDBUSR
- Descrição: Banco de dados Identity para controle de usuários, roles e claims.
- Uso: Exclusivo para gestores e desenvolvedores.
- Acesso: Restrito.
- Objetivo: Centralizar a autenticação e autorização.
¶ 4. SDBLog
- Descrição: Banco de dados de auditoria e logs do sistema.
- Uso: Exclusivo para gestores e desenvolvedores.
- Acesso: Restrito.
- Objetivo: Registro de ações e eventos do sistema.
¶ Ambiente de Produção
¶ 1. SDBCore (Desativado em Produção)
- Descrição: Banco de dados central para definições e nomenclaturas.
- Uso: Acesso somente por gestores do núcleo.
- Status: Não disponível em produção.
¶ 2. SDBERP_[IdCliente]
- Descrição: Banco de dados dedicado aos módulos do ERP para cada cliente.
- Uso: Customizações e configurações exclusivas por cliente.
- Acesso: Restrito aos gestores e desenvolvedores.
- Objetivo: Prover flexibilidade e personalização para os clientes.
¶ 3. SDBUSR
¶ Opção 1: Banco de dados centralizado na SSAG.
- Descrição: Banco único para gerenciar usuários, roles e claims de todos os clientes.
- Vantagem: Controle centralizado e fácil gerenciamento.
- Desvantagem: Possível dependência crítica em falhas.
¶ Opção 2: Banco de dados separado por cliente (SDBUSR_[IdCliente]).
- Descrição: Cada cliente possui seu próprio banco de dados Identity.
- Vantagem: Maior isolamento e controle local por cliente.
- Desvantagem: Maior complexidade para manutenção e suporte.
¶ 4. SDBLog_[IdCliente]
- Descrição: Banco de dados para armazenar os logs de cada cliente.
- Uso: Controle e auditoria de eventos específicos de cada cliente.
- Acesso: Apenas o cliente e administradores autorizados.
- Objetivo: Garantir rastreabilidade e segurança.
¶ Fluxo de Comunicação entre Bancos
- SDBCore (Dev) gera scripts de inicialização para SDBERP_[IdCliente] em produção.
- SDBUSR em produção realiza autenticação e autorização centralizadas ou segregadas.
- SDBLog_[IdCliente] registra eventos do cliente em tempo real.
- SDBERP_[IdCliente] personaliza módulos, tabelas e funcionalidades específicas por cliente.