{"id":50669082,"url":"https://github.com/rubenslyra/farmalocal","last_synced_at":"2026-06-08T09:03:25.429Z","repository":{"id":346184693,"uuid":"1188844362","full_name":"rubenslyra/farmalocal","owner":"rubenslyra","description":"Sistema de gerenciamento para farmácias locais, desenvolvido com .NET 10, focado em boas práticas de acesso a dados, arquitetura limpa e estímulo ao pensamento crítico e analítico do desenvolvedor.","archived":false,"fork":false,"pushed_at":"2026-03-22T17:22:14.000Z","size":16,"stargazers_count":0,"open_issues_count":0,"forks_count":0,"subscribers_count":0,"default_branch":"main","last_synced_at":"2026-03-23T08:08:11.850Z","etag":null,"topics":["aspnet-core","csharp","dapper","dapper-extensions","dotnet-core","farmacology","postgresql","sqlserver"],"latest_commit_sha":null,"homepage":"","language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/rubenslyra.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null,"notice":null,"maintainers":null,"copyright":null,"agents":null,"dco":null,"cla":null}},"created_at":"2026-03-22T16:57:51.000Z","updated_at":"2026-03-22T17:24:58.000Z","dependencies_parsed_at":null,"dependency_job_id":null,"html_url":"https://github.com/rubenslyra/farmalocal","commit_stats":null,"previous_names":["rubenslyra/farmalocal"],"tags_count":null,"template":false,"template_full_name":null,"purl":"pkg:github/rubenslyra/farmalocal","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/rubenslyra%2Ffarmalocal","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/rubenslyra%2Ffarmalocal/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/rubenslyra%2Ffarmalocal/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/rubenslyra%2Ffarmalocal/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/rubenslyra","download_url":"https://codeload.github.com/rubenslyra/farmalocal/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/rubenslyra%2Ffarmalocal/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":34055255,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-05-26T15:22:16.424Z","status":"online","status_checked_at":"2026-06-08T02:00:07.615Z","response_time":111,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["aspnet-core","csharp","dapper","dapper-extensions","dotnet-core","farmacology","postgresql","sqlserver"],"created_at":"2026-06-08T09:03:24.391Z","updated_at":"2026-06-08T09:03:25.422Z","avatar_url":"https://github.com/rubenslyra.png","language":null,"funding_links":[],"categories":[],"sub_categories":[],"readme":"# 💊 FarmaLocal — Modelo de Negócio + Modelo de Dados + Direção Técnica\n\n## 1. Visão geral do projeto\n\nO **FarmaLocal** é um projeto de estudos com foco em engenharia de software aplicada ao domínio farmacêutico. A proposta é desenvolver um sistema de gestão e vendas para farmácias, com base em práticas reais de mercado, permitindo estudar e comparar tecnologias como **SQL, PostgreSQL, SQL Server, C#, Dapper, APIs, aplicações desktop e futuras versões em outras linguagens e frameworks**.\n\nO projeto não deve ser tratado como um CRUD simples. Ele deve funcionar como um **laboratório de arquitetura de software**, com um domínio suficientemente rico para exigir:\n\n* modelagem relacional séria\n* regras transacionais\n* integridade referencial\n* especialização de entidades\n* rastreabilidade de estoque\n* validações regulatórias\n* separação entre núcleo operacional e extensões do domínio\n\nEm outras palavras, o FarmaLocal pode virar um projeto-âncora de portfólio técnico.\n\n---\n\n## 2. Objetivo do sistema\n\nO objetivo do FarmaLocal é permitir a gestão integrada de:\n\n* catálogo de produtos farmacêuticos e não farmacêuticos\n* medicamentos e suas particularidades regulatórias\n* estoque por lote e validade\n* vendas no balcão/PDV\n* receitas vinculadas à venda\n* clientes, convênios e histórico de compra\n* relatórios operacionais e gerenciais\n\nAlém disso, o sistema deve servir como base para diferentes implementações, mantendo o mesmo domínio e a mesma lógica de negócio.\n\n---\n\n## 3. Conceito central da modelagem\n\nO ponto mais importante do seu material está correto e deve ser preservado no desenho final:\n\n\u003e **medicamento não deve existir como um sistema isolado fora do catálogo**\n\u003e\n\u003e o correto é ter uma **base única de produtos**, com especializações para os itens que possuem exigências próprias, como medicamentos, equipamentos e itens de higiene.\n\nEssa é a abordagem mais profissional porque:\n\n* mantém o PDV unificado\n* evita duplicação de estrutura\n* facilita estoque e financeiro\n* permite especializar sem quebrar o núcleo\n* funciona melhor para expansão futura\n\nPortanto, o FarmaLocal deve nascer com uma arquitetura baseada em:\n\n### núcleo central\n\n* produto\n* categoria\n* fabricante\n* apresentação\n* estoque\n* venda\n\n### extensões especializadas\n\n* medicamento\n* princípio ativo\n* receita\n* equipamento\n* atributos extras por categoria\n\n---\n\n## 4. Modelo de negócio consolidado\n\n## 4.1. Proposta de valor\n\nO FarmaLocal oferece uma estrutura de gestão farmacêutica que une:\n\n* operação de loja\n* controle de estoque com rastreabilidade\n* suporte à venda de medicamentos sujeitos a regras\n* busca por nome comercial e princípio ativo\n* unificação de medicamentos, higiene, perfumaria, correlatos e equipamentos em um único sistema\n\nPara projeto de estudo, isso tem um valor enorme porque permite praticar cenários reais como:\n\n* venda com transação\n* controle de lote\n* integridade de estoque\n* descontos e convênios\n* busca inteligente\n* validação regulatória\n* relatórios orientados a negócio\n\n---\n\n## 4.2. Público-alvo do sistema\n\nEmbora seja um projeto de estudos, o modelo deve refletir um sistema que serviria para:\n\n* farmácias independentes\n* drogarias de bairro\n* pequenas redes\n* balcão\n* caixa\n* farmacêutico\n* gestor de estoque\n* administrador da loja\n\n---\n\n## 4.3. Problemas que o sistema resolve\n\nO sistema precisa resolver estes problemas centrais:\n\n* controlar diferentes tipos de produto em um mesmo catálogo\n* permitir a venda segura de medicamentos\n* rastrear lotes e validade\n* impedir venda irregular de itens que exigem receita\n* permitir busca por nome comercial, fabricante e princípio ativo\n* manter integridade no estoque\n* suportar descontos, convênios e histórico do cliente\n* gerar dados confiáveis para relatórios\n\n---\n\n## 4.4. Módulos do sistema\n\nO FarmaLocal pode ser dividido em módulos:\n\n### Catálogo\n\n* categorias\n* fabricantes/laboratórios\n* produtos\n* apresentações\n* princípios ativos\n\n### Medicamentos\n\n* tipo do medicamento\n* tarja\n* registro\n* exigência de receita\n* controle especial\n\n### Estoque\n\n* lotes\n* validade\n* movimentações\n* entrada e saída\n* critério FEFO\n\n### PDV\n\n* venda\n* itens\n* desconto\n* pagamento\n* vinculação ao lote\n\n### Receita e regulação\n\n* dados da receita\n* médico\n* paciente\n* retenção\n* vínculo ao item vendido\n\n### Relacionamento\n\n* cliente\n* convênio\n* histórico\n* compras por CPF\n\n### Relatórios\n\n* produtos vencendo\n* mais vendidos\n* giro por categoria\n* venda por fabricante\n* venda por princípio ativo\n* clientes recorrentes\n\n---\n\n# 5. Modelo conceitual do domínio\n\nAgora vem o merge mais importante: o seu material bruto com uma modelagem mais sólida.\n\n## 5.1. Produto como entidade-base\n\nA entidade **Produto** é a base comercial e operacional do sistema. Ela representa o item de catálogo, independentemente de ser:\n\n* medicamento\n* correlato\n* higiene\n* perfumaria\n* equipamento\n* suplemento\n\nIsso evita criar “silos” de modelagem.\n\n### Produto deve conter\n\n* identidade comercial\n* categoria\n* fabricante\n* nome de exibição\n* status de ativação\n\nMas ele **não deve carregar tudo sozinho**.\n\n---\n\n## 5.2. Apresentação como unidade vendável\n\nAqui está uma melhoria importante sobre o texto bruto: o que é vendido no PDV normalmente não é o “produto abstrato”, mas a sua **apresentação específica**.\n\nExemplo:\n\n* Produto: Paracetamol\n* Apresentação 1: Paracetamol 500mg comprimido caixa com 10\n* Apresentação 2: Paracetamol 750mg comprimido caixa com 20\n* Apresentação 3: Paracetamol gotas 200mg/ml frasco 15ml\n\nPor isso, o sistema deve ter uma tabela de **apresentação**.\n\nEssa tabela é a verdadeira unidade comercial de venda, estoque, EAN e preço.\n\n---\n\n## 5.3. Distinção entre marca, nome comercial e princípio ativo\n\nO seu material já traz essa distinção, e ela deve ser mantida.\n\n### Fabricante / laboratório\n\nÉ a empresa responsável pela marca, produção ou titularidade do produto.\n\nExemplos:\n\n* EMS\n* Medley\n* Eurofarma\n* Pfizer\n* Bayer\n\n### Nome comercial\n\nÉ o nome fantasia usado comercialmente.\n\nExemplos:\n\n* Tylenol\n* Novalgina\n* Advil\n* Aspirina\n\n### Princípio ativo\n\nÉ a substância química responsável pelo efeito terapêutico.\n\nExemplos:\n\n* Paracetamol\n* Dipirona monoidratada\n* Ibuprofeno\n* Amoxicilina\n\n### Conclusão de modelagem\n\nEntão o correto é:\n\n* **Fabricante** em tabela própria\n* **Nome comercial** como atributo do produto\n* **Princípio ativo** em tabela própria ou estrutura própria de relacionamento\n\nIsso permite:\n\n* agrupar similares e genéricos\n* buscar por substância\n* sugerir alternativa terapêutica equivalente\n* separar identidade comercial da identidade farmacológica\n\n---\n\n## 5.4. Princípio ativo e composição não são a mesma coisa\n\nEsse ponto do seu material também está correto, mas merece fechamento técnico.\n\n### Princípio ativo\n\nÉ a substância que faz efeito.\n\n### Composição\n\nÉ a fórmula completa, podendo incluir:\n\n* princípio ativo\n* excipientes\n* veículos\n* corantes\n* conservantes\n\nPara o **escopo do sistema de vendas e estoque**, você não precisa cadastrar a composição completa da bula em nível detalhado.\n\nA modelagem ideal é:\n\n* cadastrar **princípio ativo**\n* cadastrar **concentração/dosagem**\n* permitir associação de uma apresentação com uma ou mais substâncias ativas\n\nOu seja: para fins operacionais, o sistema precisa modelar o que influencia atendimento, intercambialidade, busca e venda — não necessariamente toda a formulação química da bula.\n\n---\n\n# 6. Estrutura corporativa recomendada para o banco\n\nA melhor forma corporativa para “fechar o banco” do FarmaLocal é esta:\n\n## 6.1. Estratégia geral\n\nUsar:\n\n* **modelo relacional normalizado no núcleo**\n* **tabelas especializadas para domínios específicos**\n* **integridade forte no banco**\n* **campos flexíveis só para cenários não críticos**\n\nTraduzindo:\n\n* nada de uma tabela única gigante\n* nada de jogar tudo em JSON\n* nada de duplicar informações centrais\n* especialização onde a regra muda\n* estoque por lote\n* venda por apresentação\n* medicamento com detalhes próprios\n\n---\n\n## 6.2. Grandes blocos do modelo\n\n### Núcleo mestre\n\n* categoria\n* fabricante\n* produto\n* produto_apresentacao\n* substancia_ativa\n\n### Especialização farmacêutica\n\n* medicamento_detalhe\n* apresentacao_substancia\n* receita_venda_item\n\n### Operação\n\n* fornecedor\n* lote_estoque\n* movimento_estoque\n* venda\n* venda_item\n* pagamento\n\n### Relacionamento\n\n* cliente\n* convenio\n* cliente_convenio\n\n### Governança\n\n* usuario\n* filial\n* auditoria_log\n\n---\n\n# 7. Modelo lógico consolidado\n\nAbaixo está a versão mais madura da modelagem.\n\n## 7.1. `categoria`\n\nRepresenta o macrogrupo do item.\n\n**Campos sugeridos**\n\n* id\n* nome\n* descricao\n* ativo\n\n**Exemplos**\n\n* Medicamento\n* Higiene\n* Perfumaria\n* Equipamento\n* Correlato\n* Suplemento\n\n---\n\n## 7.2. `fabricante`\n\nRepresenta a empresa/laboratório.\n\n**Campos sugeridos**\n\n* id\n* razao_social\n* nome_fantasia\n* cnpj\n* email\n* telefone\n* ativo\n\n---\n\n## 7.3. `produto`\n\nRepresenta o item-base de catálogo.\n\n**Campos sugeridos**\n\n* id\n* categoria_id\n* fabricante_id\n* nome_comercial\n* nome_reduzido\n* descricao\n* tipo_produto\n* ativo\n* data_criacao\n* data_atualizacao\n\n### Observação\n\nPara genéricos, `nome_comercial` pode ser nulo, e o sistema pode exibir algo derivado do princípio ativo + fabricante.\n\n---\n\n## 7.4. `substancia_ativa`\n\nRepresenta o princípio ativo.\n\n**Campos sugeridos**\n\n* id\n* nome\n* descricao\n* ativo\n\n---\n\n## 7.5. `produto_apresentacao`\n\nEssa é uma das entidades mais importantes do sistema.\n\nRepresenta a forma vendável do produto.\n\n**Campos sugeridos**\n\n* id\n* produto_id\n* codigo_ean\n* sku_interno\n* unidade_medida\n* quantidade_embalagem\n* forma_farmaceutica\n* dosagem_texto\n* volume_texto\n* concentracao_principal_texto\n* preco_venda\n* ativo\n\n### Exemplos\n\n* Novalgina 500mg comprimido cx 20\n* Dipirona gotas 500mg/ml frasco 20ml\n* Fralda infantil G pacote 32 un\n* Medidor de pressão digital braço\n\n---\n\n## 7.6. `apresentacao_substancia`\n\nRelaciona uma apresentação a uma ou mais substâncias ativas.\n\n**Campos sugeridos**\n\n* id\n* apresentacao_id\n* substancia_ativa_id\n* concentracao\n* unidade_concentracao\n* principal\n\n### Por que ela é importante?\n\nPorque resolve:\n\n* busca por princípio ativo\n* agrupamento de genérico/similar/referência\n* produtos com mais de uma substância\n\n---\n\n## 7.7. `medicamento_detalhe`\n\nTabela de extensão para apresentações que pertencem ao universo farmacêutico.\n\n**Campos sugeridos**\n\n* apresentacao_id\n* tipo_medicamento\n* registro_anvisa\n* tarja\n* requer_receita\n* retencao_receita\n* controlado_sngpc\n* uso_continuo\n* permite_intercambialidade\n* observacoes\n\n### Valores possíveis\n\n**tipo_medicamento**\n\n* Referência\n* Genérico\n* Similar\n\n**tarja**\n\n* Sem Tarja\n* Amarela\n* Vermelha\n* Preta\n\n---\n\n## 7.8. `fornecedor`\n\nOrigem de compra do item.\n\n**Campos sugeridos**\n\n* id\n* razao_social\n* nome_fantasia\n* cnpj\n* telefone\n* email\n* ativo\n\n---\n\n## 7.9. `lote_estoque`\n\nControla rastreabilidade, validade e quantidade do lote.\n\n**Campos sugeridos**\n\n* id\n* apresentacao_id\n* fornecedor_id\n* numero_lote\n* data_fabricacao\n* data_validade\n* quantidade_atual\n* quantidade_reservada\n* custo_unitario\n* ativo\n\n### Regra essencial\n\nA venda deve sugerir o lote com validade mais próxima, respeitando FEFO.\n\n---\n\n## 7.10. `movimento_estoque`\n\nRegistra tudo que entra e sai do estoque.\n\n**Campos sugeridos**\n\n* id\n* lote_id\n* tipo_movimento\n* quantidade\n* data_movimento\n* documento_referencia\n* origem\n* usuario_id\n* observacoes\n\n### Tipos possíveis\n\n* Entrada\n* Saída\n* Ajuste\n* Perda\n* Cancelamento\n* Inventário\n\n---\n\n## 7.11. `cliente`\n\nCadastro do consumidor.\n\n**Campos sugeridos**\n\n* id\n* nome\n* cpf\n* data_nascimento\n* telefone\n* email\n* ativo\n\n---\n\n## 7.12. `convenio`\n\nTabela de convênios ou programas de desconto.\n\n**Campos sugeridos**\n\n* id\n* nome\n* percentual_desconto\n* ativo\n\n---\n\n## 7.13. `cliente_convenio`\n\nRelacionamento entre cliente e convênio.\n\n**Campos sugeridos**\n\n* id\n* cliente_id\n* convenio_id\n* matricula\n* ativo\n\n---\n\n## 7.14. `venda`\n\nCabeçalho da venda.\n\n**Campos sugeridos**\n\n* id\n* filial_id\n* cliente_id\n* usuario_id\n* data_hora\n* subtotal\n* desconto\n* total\n* status\n\n### Status possíveis\n\n* Aberta\n* Finalizada\n* Cancelada\n\n---\n\n## 7.15. `venda_item`\n\nItens da venda.\n\n**Campos sugeridos**\n\n* id\n* venda_id\n* apresentacao_id\n* lote_id\n* quantidade\n* preco_unitario\n* desconto\n* subtotal\n\n### Regra fundamental\n\nTodo item vendido deve apontar para a apresentação e, quando controlado por lote, para o lote específico.\n\n---\n\n## 7.16. `pagamento`\n\nPagamentos vinculados à venda.\n\n**Campos sugeridos**\n\n* id\n* venda_id\n* tipo_pagamento\n* valor\n* data_pagamento\n* codigo_autorizacao\n* observacoes\n\n### Tipos possíveis\n\n* Dinheiro\n* Débito\n* Crédito\n* Pix\n* Convênio\n\n---\n\n## 7.17. `receita_venda_item`\n\nGuarda os dados de receita quando exigidos.\n\n**Campos sugeridos**\n\n* id\n* venda_item_id\n* nome_medico\n* crm\n* uf_crm\n* nome_paciente\n* cpf_paciente\n* data_emissao_receita\n* data_validade_receita\n* tipo_documento\n* receita_retida\n* observacoes\n\n### Observação\n\nEssa tabela deve ser obrigatória para itens cuja regra de negócio exigir retenção ou dados formais de prescrição.\n\n---\n\n## 7.18. `equipamento_detalhe`\n\nEspecialização opcional para equipamentos.\n\n**Campos sugeridos**\n\n* apresentacao_id\n* garantia_meses\n* numero_registro\n* possui_anvisa\n* manual_url\n* voltagem\n\n---\n\n## 7.19. `produto_atributo_extra`\n\nPara itens não críticos com grande variação de atributos.\n\n**Campos sugeridos**\n\n* id\n* apresentacao_id\n* nome_atributo\n* valor_atributo\n\nIsso serve para:\n\n* fraldas\n* aparelhos\n* itens de higiene\n* variações comerciais que não justificam novas colunas\n\n### Exemplo\n\nFralda:\n\n* tamanho = G\n* peso_suportado = 9kg a 12kg\n* quantidade_pacote = 32\n\nEsse recurso é bom, mas deve ser usado com moderação.\nNunca deve substituir os campos críticos do domínio.\n\n---\n\n# 8. Regras de negócio fechadas\n\nAgora o merge das regras precisa ficar explícito.\n\n## 8.1. Venda acontece pela apresentação\n\nO PDV nunca vende o “produto abstrato”.\nEle vende a **apresentação**.\n\n---\n\n## 8.2. Estoque é controlado por lote quando aplicável\n\nMedicamentos e vários itens farmacêuticos precisam de rastreabilidade por lote.\n\n---\n\n## 8.3. FEFO deve ser a regra padrão\n\nO lote sugerido deve ser o que vencer primeiro, desde que esteja válido e disponível.\n\n---\n\n## 8.4. Receita é obrigatória quando o item exigir\n\nSe `requer_receita = true`, o sistema precisa exigir dados mínimos de prescrição.\n\n---\n\n## 8.5. Retenção bloqueia finalização sem dados completos\n\nSe `retencao_receita = true`, a venda do item não deve ser concluída sem vínculo formal da receita.\n\n---\n\n## 8.6. Medicamento controlado exige fluxo especial\n\nSe `controlado_sngpc = true`, o sistema deve sinalizar fluxo especial e permitir futura integração/geração de dados regulatórios.\n\n---\n\n## 8.7. Busca deve ocorrer por múltiplos caminhos\n\nO balconista precisa encontrar o item por:\n\n* nome comercial\n* princípio ativo\n* EAN\n* fabricante\n* categoria\n\n---\n\n## 8.8. Genérico e referência precisam conviver no mesmo ecossistema\n\nO sistema deve permitir localizar um produto de marca e sugerir alternativas com mesmo princípio ativo.\n\n---\n\n## 8.9. Produtos não medicamentos seguem o mesmo núcleo\n\nFralda, shampoo, medidor de pressão e suplemento devem estar no mesmo catálogo central, sem criar um sistema paralelo.\n\n---\n\n# 9. Como fechar o banco de forma corporativa\n\nAqui está a resposta mais direta à sua necessidade prática.\n\n## 9.1. Fechar o banco não é só fazer o DER\n\nVocê precisa fechar:\n\n* modelo conceitual\n* modelo lógico\n* nomenclatura\n* tipos de dados\n* constraints\n* índices\n* regras de nulidade\n* regras de negócio\n* scripts de migração\n* dados iniciais\n\n---\n\n## 9.2. Dicionário de dados obrigatório\n\nCrie um documento com:\n\n* tabela\n* finalidade\n* coluna\n* tipo\n* obrigatório ou não\n* default\n* FK\n* unique\n* check\n* regra funcional\n\nSem isso, o banco fica “desenhado”, mas não governado.\n\n---\n\n## 9.3. Padronização de nomenclatura\n\nSugestão:\n\n* tabelas em `snake_case`\n* chave primária sempre `id`\n* FK sempre `xxx_id`\n* datas em `data_criacao`, `data_atualizacao`\n* booleanos sem ambiguidade:\n\n  * ativo\n  * requer_receita\n  * controlado_sngpc\n  * receita_retida\n\n---\n\n## 9.4. Integridade no banco\n\nNão deixe toda a responsabilidade só na aplicação.\n\nUse:\n\n* `primary key`\n* `foreign key`\n* `unique`\n* `check constraints`\n* `not null`\n* índices\n\n### Exemplos\n\n* `codigo_ean` único quando preenchido\n* `cpf` único para cliente\n* `quantidade_atual \u003e= 0`\n* `preco_venda \u003e= 0`\n* `data_validade \u003e data_fabricacao` quando aplicável\n\n---\n\n## 9.5. Normalização com pragmatismo\n\nA recomendação é:\n\n* núcleo em 3FN\n* sem duplicar fabricante\n* sem duplicar substância ativa\n* sem repetir categoria em tudo\n* views para leitura quando necessário\n\n---\n\n## 9.6. Versionamento do schema\n\nIsso é essencial para estudo sério e padrão corporativo.\n\nEstruture assim:\n\n```text\n/database\n  /postgresql\n    /migrations\n    /seeds\n    /views\n    /functions\n  /sqlserver\n    /migrations\n    /seeds\n    /views\n    /functions\n```\n\nCada mudança no banco deve virar migration.\n\n---\n\n# 10. Estratégia técnica para PostgreSQL e SQL Server\n\nComo você quer estudar múltiplos bancos, a melhor abordagem é:\n\n## 10.1. Mesmo modelo lógico, implementação física adaptada\n\nMantenha iguais:\n\n* entidades\n* relacionamentos\n* regras\n* nomes de tabelas\n* semântica do domínio\n\nAdapte por SGBD:\n\n* tipos\n* identity/sequence\n* funções\n* sintaxe específica\n* JSON/JSONB\n* procedures\n\n---\n\n## 10.2. Estrutura recomendada do projeto\n\n```text\n/docs\n  modelo-negocio.md\n  regras-negocio.md\n  dicionario-dados.md\n  fluxos-operacionais.md\n\n/database\n  /postgresql\n    /migrations\n    /seeds\n    /scripts\n  /sqlserver\n    /migrations\n    /seeds\n    /scripts\n\n/src\n  /FarmaLocal.Domain\n  /FarmaLocal.Application\n  /FarmaLocal.Infrastructure\n  /FarmaLocal.Api\n  /FarmaLocal.Desktop\n```\n\n---\n\n# 11. Dapper no FarmaLocal\n\nO Dapper entra muito bem nesse projeto porque o domínio exige:\n\n* consultas rápidas\n* joins claros\n* controle fino do SQL\n* transações explícitas\n* boa performance no PDV\n\n## 11.1. Onde usar Dapper\n\n* busca de produtos\n* consulta por EAN\n* listagem de estoque\n* seleção de lote FEFO\n* fechamento de venda\n* relatórios operacionais\n\n## 11.2. Onde tomar cuidado\n\n* múltiplos inserts dependentes\n* controle de estoque\n* fechamento da venda\n* cancelamento\n* baixa de lote\n\nEsses cenários devem usar transação explícita.\n\n## 11.3. Fluxo transacional de venda\n\nExemplo ideal:\n\n1. abrir transação\n2. inserir venda\n3. inserir itens\n4. validar exigência de receita\n5. baixar lote\n6. inserir pagamentos\n7. gravar movimentos de estoque\n8. commit\n\nSe qualquer etapa falhar:\n\n* rollback\n\n---\n\n# 12. Escopo ideal de MVP\n\nPara não explodir o escopo, o MVP pode ser:\n\n## Cadastro\n\n* categoria\n* fabricante\n* substância ativa\n* produto\n* apresentação\n* medicamento_detalhe\n* lote\n\n## Operação\n\n* cliente\n* venda\n* venda_item\n* pagamento\n* receita_venda_item\n\n## Regras\n\n* busca por nome comercial e princípio ativo\n* venda por apresentação\n* baixa por lote\n* FEFO\n* exigência de receita quando aplicável\n\n## Relatórios\n\n* estoque atual\n* lotes a vencer\n* itens mais vendidos\n* vendas por período\n\nEsse MVP já é muito forte para estudo.\n\n---\n\n# 13. Conclusão consolidada\n\nO merge completo entre o seu material bruto e a estrutura mais corporativa resulta nesta decisão:\n\n## Decisão oficial para o FarmaLocal\n\nO FarmaLocal deve ser construído como um **sistema de farmácia baseado em um catálogo central de produtos**, com **especializações para medicamentos e outros tipos de item**, **controle de estoque por lote**, **venda transacional por apresentação**, **regras regulatórias explícitas**, e **documentação formal do banco**, permitindo estudo sério de SQL, C#, Dapper e implementações futuras em outras stacks.\n\n## Em termos práticos, isso significa:\n\n* produto base\n* apresentação vendável\n* medicamento como extensão\n* princípio ativo separado\n* lote separado\n* venda por lote\n* receita vinculada ao item\n* banco normalizado\n* schema versionado\n* domínio reaproveitável entre PostgreSQL e SQL Server\n\n---\n\n## 📄 Licença\n\nDistribuído sob a licença MIT. Veja o arquivo [LICENSE](LICENSE) para mais detalhes.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Frubenslyra%2Ffarmalocal","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Frubenslyra%2Ffarmalocal","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Frubenslyra%2Ffarmalocal/lists"}