프로그래밍
-
[클린 아키텍처 09] 애플리케이션 조립하기프로그래밍/기타 2024. 9. 29. 13:00
왜 조립까지 신경 써야 할까?유스케이스가 영속성 어댑터를 호출해야 하고 스스로 인스턴스화한다면 코드 의존성이 잘못된 방향으로 만들어 진 것 유스케이스는 인터페이스만 알아야 하고, 런타임에 이 인터페이스의 구현을 제공받아야 한다. 그럼 객체 인스턴스를 생성할 책임은 누구에게 있을까?의존성 규칙을 어기지 않으면서 그렇게 할 수 있을까? 아키텍처에 대해 중립적이고 인스턴스 생성을 위해 모든 클래스에 대한 의존성을 가지는 설정 컴포넌트가 있어야 함! 설정 컴포넌트는 각 클래스의 인스턴스 생성 역할을 한다. 평범한 코드로 조립하기class Application { public static void main(String[] args) { AccountRepository accountRepository = n..
-
[클린 아키텍처 07] 아키텍처 요소 테스트하기프로그래밍/기타 2024. 9. 9. 17:01
테스트 피라미드어떤 종류의 테스트를 목표로 해야 하는가?- 만드는 비용이 적고, 유지보수하기 쉽고, 빨리 실행되고, 안정적인 작은 크기의 테스트들에 대해 높은 커버리지를 유지해야 한다.- 하나의 '단위'가 제대로 동작하는지 확인할 수 있는 단위 테스트 여러개의 단위와 단위를 넘는 경계, 아키텍처 경계, 시스템 경계를 결합하는 테스트는 만드는 비용이 더 비쌈, 실행이 더 느림! 테스트가 비싸질수록 테스트의 커버리지 목표는 낮게 잡아야함!그렇지 않으면 신규 기능 개발 단위 테스트, 통합 테스트, 시스템 테스트의 정의는 프로젝트마다 다른 의미를 가질 수 있다. 단위 테스트피라미드의 토대하나의 클래스를 인스턴스화하고 해당 클래스의 인터페이스를 통해 기능들을 테스트한다.만약 테스트 중인 클래스가 다른 클래스에 ..
-
[클린 아키텍처 06] 영속성 어댑터 구현하기프로그래밍/기타 2024. 9. 1. 18:50
> 영속성 어댑터 구현하기의존성 역전영속성 계층 대신 애플리케이션 서비스에 영속성 기능을 제공하는 영속성 어댑터에 대해 말해보자 application.service.Service-> application.port.out.Port 애플리케이션 서비스에서는 영속성 기능을 사용하기 위해 포트 인터페이스를 호출한다.이 포트는 실제로 영속성 작업을 수행하고 DB와 통신할 책임을 가진 영속성 어댑터 클래스에 의해 구현된다. 영속성 어댑터는 '주도되는' 어댑터다. 애플리케이션에 의해 호출될 뿐, 애플리케이션을 호출하지는 않기 때문이다. 포트는 사실상 애플리케이션 서비스와 영속성 코드 사이의 간적접인 계층이다.영속성 계층에 대한 코드 의존성을 없애기 위해 간접 계층을 추가하고 있다. 영속성 어댑터의 책임영속성 어댑..
-
[클린 아키텍처 05] 웹 어댑터 구현하기프로그래밍/기타 2024. 9. 1. 17:20
>우리가 목표로 하는 아키텍처에서 외부 세계와의 모든 커뮤니케이션은 어댑터를 통해 이루어진다! 의존성 역전웹 어댑터는 '주도하는' 어댑터다.외부로부터 요청을 받아 애플리케이션 코어를 호출하고 무슨 일을 해야하는 지 알려준다! 제어흐름adapter.in.web.Controller -> application.port.in.Port application.servcie.Service 애플리케이션 계층은 웹 어댑터가 통신할 수 있는 특정 포트를 제공서비스는 이 포트를 구현하고, 웹 어댑트는 이 포트를 호출할 수 있음 자세히 보면 의존성 역전 원칙이 적용된 걸 볼 수 있음! 왜 어댑터와 유스케이스 사이 또 다른 간접 계층을 넣어야 할까?애플리케이션 코어가 외부 세계와 통신할 수 있는 곳에 대한 명세가 포트이기 때..
-
[클린 아키텍처 04] 유스케이스 구현하기프로그래밍/기타 2024. 8. 26. 23:18
>유스케이스 구현하기유스케이스 둘러보기유스케이스를 구성하는 단계는 다음과 같다. 1. 입력을 받는다2. 비즈니스 규칙을 검증한다.3. 모델 상태를 조작한다.4. 출력을 반환한다. 입력 유효성 검증입력 유효성 검증은 어디에서 해야하는가? 바로 입력 모델이다.input parameter로 들어오는 모델(입력 모델)에서 입력 유효성 검증을 수행한다.해당 모델의 위치는 use case의 위치와 같다! because use case api의 일부이기 때문에! @Value@EqualsAndHashCode(callSuper = false)publicclass SendMoneyCommand extends SelfValidating { @NotNull private final AccountId sourceA..
-
[클린 아키텍처 03] 코드 구성하기프로그래밍/기타 2024. 8. 26. 22:10
>코드 구성하기계층으로 구성하기Web, Domain, Persistence의 구조로 패키지를 구성한다.요렇게 구성하는 경우의 문제점은? 1) 기능이나 특성을 구분짓는 경계가 없음 만약 User 기능이 추가 된다면...?서로 연관되지 않은 기능끼리 마구마구 섞임 (domain 패키지에 user repo, service, user entity 모두 추가됨 ㄷㄷ) 2) 어떤 유스케이스가 있는지 파악 불가AccountController에는 어떤 기능이 있을까..? User Controller에는..?기능으로 구성하기Account 패키지 안에 몽땅 넣는다!그 와중에 AccountService 네이밍을 SendMoneyService로 변경함이렇게 구성할 경우 '송금하기' 기능이 어딨는지 파악 가능하긴 함.. 그러..
-
[클린 아키텍처 02] Dependency Inversion (의존성 역전하기)프로그래밍/기타 2024. 8. 16. 15:34
> 의존성 역전하기백엔드 개발자라면,, 누구나 한번쯤 달달달 외웠을 SOLID 원칙! 그 중 단일 책임 원칙과 의존성 역전 원칙에 대해 자세히 살펴보도록 합시당 단일 책임 원칙우리가 흔히 아는 단일 책임 원칙은 하나의 컴포넌트는 오로지 하나의 역할만을 해야한다는 것이다.그러나 클린 아키텍처의 저자는 단일 책임 원칙을 요로케 표현했당:컴포넌트를 변경하는 이유는 오직 하나뿐이어야 한다. 컴포넌트가 변경되는 이유가 오직 하나 뿐이라면 우리가 다른 이유로 소프트웨어를 변경하더라도 이 친구는 절대 변하지 않는다는 것이다; 요렇게 세 개의 클래스가 있을 때,만약 C가 어떤 함수명을 바꿨다. 그럼 그 친구를 참조하고 있던 A와 B도 어쩔 수 없이 바꿔야함 ㅠ_ㅠ 👎👎👎C는 어느 곳에도 의존하지 않기 때문에 지..
-
[클린 아키텍처 01] What is problem of layered architecture?프로그래밍/기타 2024. 8. 16. 14:05
>'클린 아키텍처' 책 혼자서 가볍게 읽어봤지만 요번에 스터디로도 한번 더 읽게되서겸사겸사 써보는 블로그 ^___^ 코드는 깃헙에 따로 올릴 계획이다 계층형 아키텍처지금 회사 프로젝트에서 쓰고있는 계층형 아키텍처(에서 살짝 변형되긴함)는 가장 보편적으로 많이 사용되는 아키텍처인 것 같다. 개인적으로는 빠른 구현 및 코드 파악하기에는 가장 좋다고 생각함. 한 눈에 들어오잖아요? ㅎ;; 그러나 최근 계층형 아키텍처의 문제점들이 대두되면서 클린 아키텍처, 헥사고날 아키텍처를 선호하는 사람들이 많아졌는데,,그렇다면 계층형 아키텍처의 문제점은 무엇이 있느냐 문제점데이터베이스 중심의 설계위에 그래프에도 보여지듯, 웹은 도메인에 의존하고, 도메인은 영속성에 의존한다 ==> 모든 것이 결국 데이터베이스에 의존하게..