클린 아키텍처

오리젬

Robert C. Martin은 자신의 블로그에 다음과 같은 자격을 부여하지 않습니다. 건축 양식 육각형을 클린 아키텍처 비자로 보호하기 위해 자신의 블로그를 보호하고 보호해야 합니다.

Pontos Importantes Sobre Arquitetura

정의 o 형식 que o 소프트웨어 terá

Responsável por dividir os componentes de forma clara

Os componentes precisam ter formas de se comunicar um com o outro

Uma boa arquitetura deve ajudar a tornar um sistema fácil de manter, melhorar, entender e fazer o deploy.

사용 사례

Casos de uso expressa, uma intenção de uma ação que o que o software realiza. Cada comportamento deve ser claro. Detalhes não devem impactar nas regras de negócio. Frameworks, bancos de dados e apis não devem impactar nas regras de negócio.

Cada 사용 사례는 책임 있는 원칙에 따라 결정됩니다.
예: Alterar e inserir um produto são semelhantes, ambos realizam uma Consulta no banco de dados e fazem uma persistência. useCases가 다릅니다. Ou seja semper que a intenção da alteração é diferente deve ser um useCase diferente

사용 사례 contam uma historia

Na imagem um exemplo do fluxo de juntar as informações de contato para gerar um novo empréstimo. É enumerado uma lista de passos que a aplicação deve seguir para esse use case

유효한 이름

Validar o endereço 등

Pegar o 신용 점수.

Se o 점수는 500 recusar에 대한 크레딧입니다.

Criar o cliente e ativar a estimativa de empréstimo

한계 건축

Tudo que não impacta diretamente nas regras de negócio deve estar em um limite arquitetural diferente.
예: não será o frontend, banco de dados que mudará as regras de negocio da aplicação.



as regras de negocio chamam uma interface para se comunicar com o banco de dados, eo 데이터베이스 액세스 implementa esse banco de dados, fazendo que as regras de negócios não 정밀 세이버 nada sobre o banco de dados, somente sobre a 인터페이스

DTO(데이터 전송 객체)

최종 das contas tudo é 입력 e 출력이 없습니다. Dessa forma podemos simplificar nosso raciocínio ao criar um software pensando dessa forma. O DTO contem os dados ou do input ou do output

Ele é responsável por pegar esseses dados and transportar pelos limites arquiteturais. Além disso o DTO é um objeto anêmico, ele não possui regras, apenas possui dados.

Geralmente cada intenção dos sistema precisa de DTOS diferentes, por exemplo criar um produto e fazer update no produto precisam de campos diferentes, no mínimo o update precisa de 1 campo a mais (o ID)

발표자

Objetos de transformação, a função deles é adquar um DTO que lhe foi inputado para um formato correto de entregar um resultado, Ex.: JSON, Protobuf, GraphQl, CLI, etc.

  input = new CategoryInputDto("name")
  output = CreateCategoryUseCase(input);
  jsonResult = CategoryPresenter(output).toJson();

Nesse exemplo passamos o DTO de input e recebemos um dto de output, e ai usamos o presenter para transformar esse dto de output em um objeto json e retornar para o usuario

엔티티

DDD를 수행하는 다른 클린 아키텍처를 사용하려고 합니다. 클린 아키텍처는 DDD를 사용하지 않고 정의할 수 있으며 응용 프로그램을 대표할 수 있습니다.

Como a clean architecture는 entidade como uma camada da regra de negocio elas se aplicam em qualquer situação를 정의합니다.

Não는 DDD를 수행하는 방식으로 정상적인 기공을 유발하는 명백한 원인이 존재하며 도메인 서비스가 DDD를 수행하는 경우 도메인 서비스가 DDD를 수행할 때 도메인 서비스가 깨끗해질 수 있는 원칙을 제시합니다.