4. Especificação Técnica do Sistema - Moutt/ENGENHARIA-DE-SOFTWARE GitHub Wiki

Especificação dos Modelos UML de Projeto

1. Modelos de Interação para realização dos casos de uso

UC01 - EXPLORAR PROJETO

UC1(4 0)

UC02 - REALIZAR PROJETO UC2(4 0)

UC03 - AVALIAR EMPRESA UC3(4 0)

UC04 - AVALIAR PRESTADOR DE SERVIÇO UC4(4 0)

UC05 - CONCLUIR PROJETO UC5(4 0)

UC06 - PUBLICAR PROJETO UC6(4 0)

UC07 - RETIRAR PROJETO UC7(4 0)

2. Diagrama de Classes de Projeto

diagrama de projeto diagrama de projeto2

1. Entidades de Domínio & Apoio

Classe	Tipo	Atributos-chave	Operações-chave
Usuario	Abstrata	`id`, `nome`, `email`, `senhaHash`, `tipo : UserType`	—
Empresa	← `Usuario`	`cnpj`, `telefone`, `endereco`, `razaoSocial`	—
Fornecedor	← `Usuario`	`avaliacaoMedia`	—
Projeto	Domínio	`id`, `titulo`, `descricao`, `dataCriacao`, `dataEntregaPrevista`, `status : ProjectStatus`	`publicar()`, `fechar()`
Proposta	Domínio	`id`, `valor`, `prazo`, `dataEnvio`, `status : ProposalStatus`	`enviar()`, `atualizarStatus()`
Contrato	Domínio	`id`, `dataInicio`, `valorTotal`, `status : ContractStatus`	`ativar()`, `concluir()`, `cancelar()`
Notificacao	Apoio	`id`, `mensagem`, `dataHora`, `lida : Boolean`	`marcarComoLida()`
HistoricoProjeto	Apoio	`id`, `acao`, `dataHora`	—
DocumentacaoProjeto	Apoio	`id`, `arquivoUrl`, `dataUpload`	—

2. Controllers (Camada de Aplicação)

Classe	Estereótipo	Operações Expostas	Usa / Cria
ProjetoController	`<<controller>>`	`postProjeto(dto)`, `listProjetos(filtro)`, `fecharProjeto(id)`	`Projeto`, `Empresa`
PropostaController	`<<controller>>`	`createProposta(dto)`, `listPropostas(idProjeto)`, `aceitarProposta(id)`	`Proposta`, `Projeto`, `Fornecedor`, `Contrato`
NotificacaoController	`<<controller>>`	`listNotificacoes(usuarioId)`, `marcarLida(notificacaoId)`	`Notificacao`
AuthController	`<<controller>>`	`login(dto)`, `logout(token)`	`Usuario`

3. Enums

Enum	Valores
ProjectStatus	`OPEN`, `IN_PROGRESS`, `CLOSED`
ProposalStatus	`PENDING`, `ACCEPTED`, `DECLINED`
ContractStatus	`ACTIVE`, `COMPLETED`, `CANCELED`
UserType	`ADMIN`, `MODERATOR`, `COMPANY`, `SUPPLIER`

3. Diagrama de Componentes com as Interfaces Explícitas

1.COMPONENTES BACK-END

2.SUBSISTEMA DE NOTIFICAÇÃO ASSINCRONA

![subsistema de notificação assincrona] 442532806-3369c422-5fb0-4588-a2cd-fa1d3c7004e9

4. Especificação de Táticas, Padrões de Projeto e Arquitetura

Suporte às decisões de projeto do sistema de Marketplace de Projetos & Propostas

Este documento consolida táticas de qualidade (SEI/ATAM), padrões GoF & Enterprise,
e o estilo arquitetural adotado. Ele serve como guia para o time avaliar, justificar e comunicar suas decisões em cada sprint de evolução.

1. Visão-geral

Item	Descrição
Domínio	Publicação de projetos por Empresas e envio/aceite de propostas por Fornecedores
Camadas	UI → REST Controllers → Application Services → Domain → Repositories
Estilo	• Clean / Hexagonal (Ports & Adapters) • Event-Driven para processos assíncronos • Relational DB + opcional cache Redis
Tecnologias (pré-decisão)	Spring Boot / Node, PostgreSQL, RabbitMQ (bus), JWT, Docker/K8s

2. Matriz de Qualidades × Táticas × Padrões

Qualidade (QA)	Tática adotada	Padrão / Prática	Como será aplicado	Trade-off
Modificabilidade	Separation of Concerns	Layered Architecture, Controller-Service-Repository, DTO	Classes de interface REST isolam DTOs; Serviço orquestra domínio; Repositórios encapsulam JPA/SQL	+Clareza / Pequeno overhead de camadas
	Plugin/Replaceable Components	Interface (lollipop) + DI	Controllers dependem de `IProjetoService`, etc.	+Mock fácil / +Hot-Swap
Performance	Asynchronous Execution	Event Bus, Observer	`PropostaAceita` → fila → `NotificationService`	+Escalável / +Dev-Ops
	Caching	Repository-Cache Layer, Singleton do cache	Projetos abertos via Redis	+Resposta / Coerência eventual
Escalabilidade	Stateless Services	(possível) Microservice decomposition	Cada Controller + Service → pod/replica	+Horizontal scale / +Ops overhead
	Data Partitioning	Schema-per-Tenant / Sharding	partição por empresa	+Throughput / Consultas mais complexas
Disponibilidade	Retry + Timeout	Circuit Breaker, Retry Pattern	Client→Bus / DB drivers	+Resiliência / +Código
	Failover	Replica DB, Health Check	K8s liveness probes, read-replicas	+MTTR baixo / +Custo infra
Segurança	Autenticação	JWT, Singleton AuthProvider	`AuthController → AuthProvider`	+Escalável / Revogação imediata difícil
	Autorização	RBAC, Policy Enforcer	Anotações `@PreAuthorize`, enum `UserType`	+Granular / Gerência de papéis
Testabilidade	Dependency Substitution	Factory Method, Builder Test	Mocks para `IProjetoRepository`	+Cobertura / Boilerplate
Observabilidade	Log & Trace	Decorator para log, AOP	Interceptador REST → ELK	+Visibilidade / Overhead I/O

3. Padrões de Projeto (GoF / Enterprise) Selecionados

Categoria	Padrões aplicados	Papel no sistema
Criacionais	Factory Method (criar Proposta/Contrato a partir de DTO) Singleton (AuthProvider, RedisCache)	Remove `new` espalhado & garante instância única
Estruturais	Facade (Auth API, Notification API) Repository / DAO Adapter (gateway de e-mail externo)	Desacoplamento de subsistemas e de persistência
Comportamentais	Observer / Event Publisher Strategy (cálculo de preço / ranking) Template Method (validação base × específica)	Extensões sem alterar núcleo

4. Decisões Arquiteturais (snapshot de ADRs)

Nº	Decisão	Forças & Motivos	Status
ADR-001	Adotar Clean Architecture	Facilita testes, mudança de frameworks, integração de bus	Aceita
ADR-002	Eventos de Domínio via RabbitMQ	Remove acoplamento síncrono; escalável	Aceita
ADR-003	JWT + Stateless Auth	Alinha com pods autoscaláveis	Aceita
ADR-004	Repository Pattern com UoW implícita	Consistência transacional por request	Aceita
ADR-005	Cache Redis para leitura pública	Balanceia performance × consistência	Provisório

Próximos passos
• Validar ADR-005 em testes de carga
• Avaliar tática “Bulkhead” caso multitenant
• Versionar mensagens no schema-registry

5. Traceabilidade para os Casos de Uso

Caso de uso	Táticas / Padrões relevantes
Publicar Projeto	Controller → Service → Factory Method; Repository; Cache miss-after-commit
Enviar Proposta	Factory Method; Repository; Transaction Scope
Aceitar Proposta	Domain Event → Observer → NotificationService; Retry + Circuit Breaker no e-mail
Login / JWT	AuthController → AuthProvider (Singleton); Strategy (hash)
Listar Projetos Abertos	Redis Cache; Read-replica DB; Pagination Strategy

6. Checklist de Implementação

Interfaces (I*Service, I*Repository) publicadas conforme diagrama de componentes
Eventos de domínio serializados em JSON Schema
Handlers externos encapsulados por Adapter + testes de contrato
Factory Methods retornam objeto válido (usar validation template)
Cobertura ≥ 80 % em Services e Domain (mocks via DI)
Log decorado em todos os Controllers (AOP / Decorator)

Referências

Bass, Clements & Kazman — Software Architecture in Practice (Táticas)
Gamma et al. — Design Patterns – GoF
Vernon — Implementing Domain-Driven Design (Layers, Events)