클린 코드(Clean Code)/만들면서 배우는 클린 아키텍처 요약
-
4장 - 유스케이스 구현하기클린 코드(Clean Code)/만들면서 배우는 클린 아키텍처 요약 2023. 2. 24. 00:01
도메인 모델 구현하기 한 계좌에서 다른 계좌로 송금하는 유스케이스를 구현합니다. 객체지향적인 방식으로 모델링하기 위해 입금과 출금을 할 수 있는 Account 엔티티를 만들고 출금 계좌에서 돈을 출금해서 입금계좌로 돈을 입금해야 합니다. 해당 엔티티는 withdraw()라는 출금 메서드를 가지고, deposit()이라는 입금 메서드를 통해 입출금을 수행할 수 있습니다. 또한 출금하지 전에는 잔고를 초과하는 금액을 출금할 수 없도록 하는 비즈니스 규칙을 검사합니다. 유스케이스 둘러보기 일반적으로 유스케이스는 다음과 같은 단계를 따릅니다. - 입력 받기 - 비즈니스 규칙 검증 - 모델 상태 조작 - 출력 반환 유스케이스는 인커밍 어댑터로부터 입력을 받으며 이 단계에서 유효성 검증은 이루어지지 않습니다. 유스..
-
3장 - 코드 구성하기클린 코드(Clean Code)/만들면서 배우는 클린 아키텍처 요약 2023. 2. 22. 00:01
계층으로 구성하기 웹, 도메인, 영속성 계층으로 패키지를 나눈 모습입니다. DIP를 통해 domain 패키지에 있는 코드만을 가리키도록 했습니다. 하지만 애플리케이션의 기능 조각이나 특성을 구분 짓는 패키지 경계가 없습니다. 관리자 기능을 추가하기 위해서는 web 패키지에 UserController를 추가하고 domain 패키지에 UserService, UserRepository, User를 추가하고, persistence 패키지에 UserRepositoryImpl을 추가해야 합니다. 이렇게 되면 서로 연관되지 않은 기능들끼리 예상하지 못한 부수효과를 일으킬 수 있게 됩니다. 또한 특정 기능을 찾기 위해 어떤 서비스가 이를 구현했는지 추측하고, 해당 서비스 내의 어떤 메서드가 그에 대한 책임을 수행하는지..
-
2장 - 의존성 역전하기클린 코드(Clean Code)/만들면서 배우는 클린 아키텍처 요약 2023. 2. 21. 00:01
단일 책임원칙 컴포넌트를 변경할 이유가 오로지 한 가지라면 컴포넌트는 딱 한 가지 일만 하게 됩니다. 이는 어떤 다른 이유로 소프트웨어를 변경하더라도 이 컴포넌트에 대해서는 전혀 신경 쓸 필요가 없음을 의미합니다. 하지만 변경할 이유는 컴포넌트 간의 의존성을 통해 너무 쉽게 전파됩니다. 예를 들어 컴포넌트 E를 변경할 유일한 이유는 새로운 요구사항에 의해 E의 기능을 바꿔야 할 때 뿐입니다. 하지만 컴포넌트 A의 경우 모든 컴포넌트에 의존하고 있기 때문에 다른 어떤 컴포넌트가 바뀌든지 같이 바뀌어야 합니다. 예를 들어 AController에서 BService, CService를 참조하고 있습니다. 이때 BService의 이름이 BBService로 바뀐다면? E 컴포넌트는 바뀔 필요가 없지만 AContro..
-
1장 - 계층형 아키텍처의 문제는 무엇일까?클린 코드(Clean Code)/만들면서 배우는 클린 아키텍처 요약 2023. 2. 20. 00:01
전통적인 계층형 아키텍처 1. 웹 계층에서 요청을 받음 2. 도메인 혹은 비즈니스 계층에 있는 서비스로 요청을 보냄 3. 도메인 엔티티의 현재 상태를 조회하거나 변경하기 위해 영속성 계층의 컴포넌트 호출 계층형 아키텍처의 문제점 웹 -> 도메인 -> 영속성으로 이어지기 때문에 자연스럽게 데이터베이스에 의존하게 됩니다. 이렇게 되면 '도메인 로직'이 아니라 '데이터베이스'를 토대로 아키텍처가 만들어집니다. 전통적인 계층형 아키텍처에서는 합리적인 방법입니다. 하지만 비즈니스 관점에서는 전혀 맞지 않는 방법입니다. 이렇게 된 가장 큰 원인은 ORM 프레임워크를 사용하기 때문입니다. ORM에 의해 관리되는 엔티티들은 일반적으로 영속성 계층에 두게 되고 도메인 계층 사이에 강한 결합이 생기게 됩니다. 서비스는 영..