Estrutura de Pastas | Portal de Documentação

Guia de programação
Padrões Delphi
Filosofias
Interface Commerce
Uso de componentes
Mais sobre Interface
Documentação em Fontes
Estrutura de Pastas

Esse artigo possui definições a respeito da estrutura de pastas do Totali Commerce. Os tópicos são referentes a uma versão do Totali Commerce, ou seja, a partir da pasta versão.

Geral

Na raiz da versão encontra-se TOTALI.COP com dados referentes a versão do Totali Commerce.
E alguns bats utilizados pelo compilador para compilar a versão.

Estrutura Antiga (Delphi 7)

As pastas que iniciam com letras minúsculas na raiz da versão são da estrutura antiga.
Elas podem ser de dois tipos:
Pastas de projeto:
Exemplo: totali2000backoffice

Pastas de negócio:
Exemplo: bkoffice

Nas pastas de projeto ficam os arquivos de projeto do Delphi (DPR e derivados).
E também a tela de menu principal única e inseparável do projeto, normalmente chamada de TTFPRINC.

Nas pastas de negócio ficam espalhas as units de telas, data modules, relatórios, procedures e até de classes.
Essas pastas podem ter até um nível de divisão caso o negócio seja muito complexo.

Estrutura Nova (Delphi XE)

Por conta da utilização da versão XE 7 do Delphi resolvemos criar uma divisão de pastas que nos ajude a separar os fontes que são feitos para Delphi 7 dos fontes que são do Delphi XE 7.
É claro que projetos no Delphi 7 poderão utilizar esses novos fontes, desde que seja utilizado diretivas de compilação para manter compatibilidade entre os dois.
Uma classe nova utilizada somente para Delphi 7 não deve ser criada na nova estrutura, porque quando formos utilizá-la em Delphi XE 7 não saberemos que ela não está preparada para isso.

Ideia: definirmos comentário padrão na UNIT e indicar nele se ela é compatível com Delphi 7 ou Delphi XE 7.

Pasta Projetos

Projetos/Delphi7/<Nome do Projeto em CamelCase>/<Arquivos do Projeto com Nome Curto (Executável)> Projetos/DelphiXE7/<Nome do Projeto em CamelCase>/<Arquivos do Projeto com Nome Curto (Executável) >

Projetos de Delphi 7

Criar projetos compilados em Delphi 7.
Utilizar o nome completo do produto sem espaços e no estilo CamelCase.
Exemplo: TotaliImportService

Dentro dessa pasta o DPR deve ser criado com o nome curto usado como executável.
Exemplo: TTImportSrv.

Projetos de Delphi XE 7

Criar projetos compilados em Delphi XE 7.
Utilizar o nome completo do produto sem espaços e no estilo CamelCase.
Exemplo: TotaliMiddlewareService.

Dentro dessa pasta o DPR deve ser criado com o mesmo nome da pasta.
Os projetos do Totali 2000 possuíam nomes curtos, mas para nova geração mudamos o paradigma. Exemplo: TotaliMiddlewareService.dpr -> TotaliMiddlewareService.exe.

Pasta Telas

Telas/<Nome do Projeto em CamelCase> Telas/combos

Telas de Sistema

Dentro dela a principal divisão é pelo nome do projeto no qual ela foi primeiramente utilizada.

Combos

Em Telas também existe uma pasta combos. Nela devemos centralizar a criação de combos baseados em objetos, e não em conexão com banco. Cada combo deverá ser uma nova classe e poderão ser utilizados livremente por todos os projetos. Os que serão baseados em enums serão mais livres. Os que serão baseados em classes de negócio dependem que o projeto em que serão utilizados conheça a classe de negócio que ele precisa.

Pasta Estruturas

Estruturas/<owner>/estrutura.sql Estruturas/<owner>/upgrade/<passos de migração da versão anterior para a versão atual>

A pasta estrutura é organizada por "Owner" do banco. Se um dia quisermos ter a estrutura do Commerce definida nessa pasta, criaríamos uma pasta totali e nela teríamos um arquivo estrutura.sql com toda a definição do banco (criação de tabelas, triggers, funções, etc.).

Como a estrutura em si está dentro de uma versão com Totali Commerce, seria necessário ter uma pasta de upgrade para termos separado o que foi modificado em relação a versão anterior.

Pasta Classes

Classes/<Grupos de Negócio> Classes/<Projetos em Camel Case> Classes/geral

As pastas serão divididas em grupos de negócio, que são divisões quase por produtos para separar negócios que são mais separados. Quando pensamos que determinado assunto poderá virá um produto, ele deverá ser separado em um novo grupo de negócio.

Checkout: Classes que são feitas baseadas nas regras de negócio da frente de caixa e balcão (Checkout e Order).
Commerce: Classes que são feitas baseadas nas regras de negócio do ERP (Backoffice e Delivery).
Impostos: Classes que são responsáveis por cálculo de impostos do sistema.
Middleware: Classes que são responsáveis camada de serviços feitas em Delphi.
Nfe: Classes que são responsáveis pela mensageria e conversões de NF-e e suas derivações.
Geral: Classes de utilidade pública que devem ser implementadas com o mínimo de dependências possível para que todos os projetos possam utilizá-las.

Divisões por Grupo de Negócio

Classes/<Grupo de Negócio>/api Classes/<Grupo de Negócio>/dao Classes/<Grupo de Negócio>/geral Classes/<Grupo de Negócio>/negocio

Dentro de um grupo de negócio teremos algumas divisões padrões.

API: Classes que contém os serviços expostos para aquele grupo de negócio.
DAO: Classes que conectam nos mais variados acessos a dados.
Geral: Classes de utilidade geral que tenha relação com aquele grupo de negócio.
Negocio: Classes responsáveis pelos negócio em si. Entidades, cálculos, conversores, etc.

Divisões por API

Classes/<Grupo de Negócio>/api/<externos> Classes/<Grupo de Negócio>/api/interna

A divisão por API possui as seguintes divisões:

Externos: São classes expostas para diversos tipos de clients. Dividimos em categorias que ajudem a definir a tecnologia de cada API. As conhecidas são: SOAP, JSON, XML e DLL.
SOAP: ficariam interfaces das classes SOAP geradas pelo Delphi e classes de parâmetros utilizadas nas implementações dessas interfaces.

As classes utilizadas como parâmetro precisam estar ali porque caso elas mudem, os métodos expostos mudarão também.
Nosso modelo não prevê a possibilidade de ter versionamento dos métodos SOAP.

JSON: ficariam os serviços acessíveis externamente e a conversão dos dados de JSON para classes de negócio.
XML: seriam classes que compreendem um formato de XML e fazem classes de negócio.
DLL: são os métodos expostas pela DLL, normalmente com export e sdtcall.

Divisões por DAO

Classes/<Grupo de Negócio>/dao/fabrica Classes/<Grupo de Negócio>/dao/acesso Classes/<Grupo de Negócio>/dao/<especificação>

A classe DAO deve abstrair a origem dos dados e deve acessar classes específicas para cada tipo de conexão.
No caso do grupo de negócio Commerce definimos que as classes DAO se chamariam "BancoDAO" e acessariam o banco de maneira ANSI (Para Oracle e PostgreSQL).
Se precisarmos algum dia escrever métodos específicos para Oracle e PostgreSQL, podemos estender a classe BancoDAO para PostgreSQL ou Oracle e fazer com que a fábrica passe a instanciar o objeto correto.
Todas essas classes ficariam dentro da pasta DAO, mas cada conexão específica teria uma pasta ali dentro.

Fabrica: devem ser objetos estáticos que somente decidem que tipo de objeto DAO deve ser instanciado.

Objetos DAOs nunca podem ser instanciados fora de uma fábrica.
E as fábrica deve ser centralizada para que a configuração de qual DAO utilizar sem única.

Acesso: Classes que acessam dado abstraindo a origem dos mesmos.

As classes de negócio devem enxergar apenas as classes DAO.
E a instancia do objeto da classe DAO deve definir de onde os dados devem ser obtidos.

Especificação: Para ficar mais claro a origem dos dados podemos criar uma pasta para agrupar as classes específicas para aquela origem de dados.