일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 |
- 만들면서배우는클린아키텍처
- 유지보수
- 도메인 주도 개발 시작하기
- 아키텍처
- 헥사고날아키텍처
- 코틀린
- 계층형아키텍처
- GrokkingFunctionalProgramming
- 책스터디
- 클린아키텍처
- Java
- web
- 개발서적
- 함수형프로그래밍
- 조영호
- TDD
- Spring
- 스터디
- template
- Boot Legacy 차이점
- DDD
- 객체지향의사실과오해
- 이펙티브코틀린
- Kotlin
- FP
- Thymeleaf
- 개발방법론
- 테스트주도개발
- 추상화 설계
- 테스트
- Today
- Total
목록전체 글 (84)
김동형수 개발기

웹 어댑터 구현하기 오늘날의 애플리케이션은 대부분 웹 인터페이스 같은 것을 제공한다. 웹브라우저와 상호작용하는 UI, HTTP API가 여기에 해당한다. 클린아키텍처에서 외부 세계와의 모든 커뮤니케이션은 어댑터를 통해서 이뤄진다. 의존성 역전 웹 어댑터는 외부로부터 요청을 받아 애플리케이션 코어를 호출하고 무슨 일을 해야 할지 알려준다. 이떄 제어의 흐름은 컨트롤러(웹 어댑터) -> 서비스(애플리케이션 계층) 으로 흐른다. 애플리케이션 계층은 웹 어댑터가 통신할 수 있는 특정 포트를 제공한다. 서비스에서 포트 인터페이스를 구현하고 컨트롤러에선 포트 인터페이스의 의존성 주입을 통해 호출할 수 있다. 직접호출할 수 있지만, 애플리케이션 코어가 외부와 통신할 수 있는 곳에 대한 명세가 포트이기 때문이다. 서비..

유스케이스 구현하기 앞 챕터에서 설명한 내용으로 애플리케이션, 웹, 영속성 계층이 현재 아키텍처에서 아주 느슨하게 결합돼 있기 때문에 필요한 대로 도메인 코드를 자유롭게 모델링할 수 있다. 헥사고날 아키텍처는 도메인 중심의 아키텍처에 적합하기 때문에 도메인 엔티티를 만드는 것으로 시작한 후 해당 도메인 엔티티를 중심으로 유스케이스를 구현하겠다. 도메인 모델 구현하기 Account 엔티티는 실제 계좌의 현재 스냅숏을 제공한다. 계좌에 대한 모든 입금과 출금은 Activity 엔티티로 포착된다. 현재 회사에서 MSA환경에서 다른 모듈과 데이터 동기화할때 http통신(service mesh) / kafka 를 이용한 데이터 동기화를 하고 있는데, 이때 Activity를 이용해서 kafka에 적재하면 좋을 것 ..

코드 구성하기 코드를 보는 것만으로도 어떤 아키텍처인지 파악할 수 있다면 좋지 않을까? 새 프로젝트에서 괜찮아 보이는 구조를 잡지만, 프로젝트가 계속해서 진행될수록 패키지 구조는 짜임새 없는 엉망진창 코드를 그럴싸하게 보이게 만드는 껍데기 뿐이라는 점을 깨닫게 된다. 뼈를 세게 얻어 맞았다. 효과는 굉장했다. 저자는 BuckPal 예제 코드를 구조화하기 위한 여러 방법을 살펴본다. '송금하기' 유스케이스를 예로 들어서 프로젝트 구조를 구성해보자. 계층으로 구성하기 웹, 도메인, 영속성 계층 각각에 대해 전용 패키지인 web, domain, persistence를 뒀다. 의존성 역전 원칙을 적용하기 위해서 AccountRepository 인터페이스를 domain 패키지에 배치하고 그 구현 클래스는 pers..

02. 의존성 역전하기 객체지향 개발을 잘 하기위한 방법인 'SOLID' 원칙 중 단일 책임 원칙, 의존성 역전 원칙에 대해 다룬다. 단일 책임 원칙 'SOLID' 원칙 중 'S'에 해당하며, 일반적인 해석은 아래와 같다 하나의 컴포넌트는 오로지 한 가지 일만 해야 하고, 그것을 올바르게 수행해야 한다. 그러나 저자의 관점에서는 '책임' = '변경할 이유'라고 해석해서 단일 책임 원칙을 아래와 같이 해석한다. 컴포넌트를 변경하는 이유는 오직 하나뿐이어야 한다. 만약 컴포넌트를 변경할 이유가 한 가지라면 우리가 어떤 다른 이유로 소프트웨어를 변경하더라도 그 이유에 해당하지 않는 컴포넌트에 대해서는 신경쓸 필요가 없다. 변경할 이유라는 것은 컴포넌트 간의 의존성을 통해서 쉽게 전파가 된다. 컴포넌트간 의존성..
01. 계층형 아키텍처의 문제는 무엇일까? 일반적인 웹어플리케이션의 계층형 아키텍처 웹 -> 도메인(비즈니스) -> 영속성 잘 만들어진 계층형 아키텍처는 변화하는 요구사항과 외부 요인에 빠르게 적응할 수 있게 해준다. 계층형 아키텍처는 데이터베이스 주도 설계를 유도한다. 계층형 아키텍처에서 의존도 웹 -> 도메인, 도메인 -> 영속성 삼단논법에 의거해서 웹 -> 영속성 의존이라는 결론 도출! LIFIC 계층형 구조에서의 용어정리 웹 - 컨트롤러 도메인 - 서비스, 컴포넌트 영속성 - 리파지토리, 엔티티 영속성(데이터베이스)에 의존적인 계층형 아키텍처 실제로 개발하다보면 엔티티 의존적인 코드를 구현하고는 한다. 우리는 대체로 데이터베이스 모델링 -> 도메인 로직의 순서로 개발했을 것이다. 비지니스 관점에서..
Intro 스프링에서 컨트롤러 작성할 때 API용은 RestController Annotation을 사용하고 Dispatcher Servlet으로 보내야 하는 경우( 페이지 이동 ) 에는 Controller Annotation을 사용합니다. 하지만 왜 사용하는지, 어떤 차이가 있는지는 몰랐습니다. 케이스 바이 케이스로 공식 외우듯 기계처럼 작성을 해왔습니다. 하지만 오늘은 두 Annotation을 소화해보려고 합니다. Content @Controller가 있는 Request가 발생하면 어떠한 일이 일어날까? 아주 잘 설명되엉 있는 그림이 첨부된 포스팅을 발견했습니다. 개인적인 생각으로 가장 중요한 내용은 클라이언트에서 Controller로 요청(Request)을 하게되면 Spring의 Dispatcher..
Intro 군대에 입대해서 처음 개발에 몸을 담굴 때 Spring Framework라는 것을 처음 접했습니다. 그때는 뭔지도 모르고 사용하고 있었고 지금도 희미하게 알고 사용하지만 '왜' 사용하는지는 모르고 있었습니다. 어떠한 장점이 있고 Framework는 뭐고 Spring Framework가 뭐가 좋길래 사용하는지 늦었지만 알아보고자 합니다. Content Framework란? 위키백과에서 확인해본 결과 소프트웨어 프레임워크(software framework)는 복잡한 문제를 해결하거나 서술하는 데 사용되는 기본 개념 구조이다. 간단히 뼈대, 골조(骨組), 프레임워크(framework)라고도 한다. 이렇게 매우 폭넓은 정의는 이 용어를 버즈워드(buzzword)로서, 특히 소프트웨어 환경에서 사용할 ..
Intro 예전에는 공통 로직을 담당하는 모듈을 jar형태로 배포하는 방법이 있었습니다. MSA가 등장하면서 대체되었지만 상황에 따라서는 jar형태의 라이브러리로 배포해야하는 상황이 발생할 수 있습니다. 지속적인 http통신이 부담스럽다거나 통신을 하지 않아도 될 만큼의 작업이거나, 보안상 통신을 할 수 없을 때 등 그런의미에서 Gradle을 사용해서 private한 nexus repository에 jar형태로 deploy하는 방법을 정리해볼까 합니다. ※ 작성하는 Gradle의 버전은 5.x 버전을 기준으로 합니다. Content jar로 빌드하면서 포함될 소스를 지정하기 위해서 gradle의 sourceSets 블럭을 사용해서 java source root와 resources 폴더를 지정해줍니다. 해..