일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 | 31 |
- 스터디
- 함수형프로그래밍
- Java
- DDD
- 이펙티브코틀린
- GrokkingFunctionalProgramming
- Boot Legacy 차이점
- template
- 테스트
- 개발방법론
- 테스트주도개발
- 만들면서배우는클린아키텍처
- 도메인 주도 개발 시작하기
- Kotlin
- 개발서적
- FP
- TDD
- Spring
- 클린아키텍처
- 아키텍처
- 추상화 설계
- 객체지향의사실과오해
- 헥사고날아키텍처
- 유지보수
- web
- 계층형아키텍처
- Thymeleaf
- 코틀린
- 조영호
- 책스터디
- Today
- Total
목록유지보수 (11)
김동형수 개발기
유스케이스 구현하기 앞 챕터에서 설명한 내용으로 애플리케이션, 웹, 영속성 계층이 현재 아키텍처에서 아주 느슨하게 결합돼 있기 때문에 필요한 대로 도메인 코드를 자유롭게 모델링할 수 있다. 헥사고날 아키텍처는 도메인 중심의 아키텍처에 적합하기 때문에 도메인 엔티티를 만드는 것으로 시작한 후 해당 도메인 엔티티를 중심으로 유스케이스를 구현하겠다. 도메인 모델 구현하기 Account 엔티티는 실제 계좌의 현재 스냅숏을 제공한다. 계좌에 대한 모든 입금과 출금은 Activity 엔티티로 포착된다. 현재 회사에서 MSA환경에서 다른 모듈과 데이터 동기화할때 http통신(service mesh) / kafka 를 이용한 데이터 동기화를 하고 있는데, 이때 Activity를 이용해서 kafka에 적재하면 좋을 것 ..
02. 의존성 역전하기 객체지향 개발을 잘 하기위한 방법인 'SOLID' 원칙 중 단일 책임 원칙, 의존성 역전 원칙에 대해 다룬다. 단일 책임 원칙 'SOLID' 원칙 중 'S'에 해당하며, 일반적인 해석은 아래와 같다 하나의 컴포넌트는 오로지 한 가지 일만 해야 하고, 그것을 올바르게 수행해야 한다. 그러나 저자의 관점에서는 '책임' = '변경할 이유'라고 해석해서 단일 책임 원칙을 아래와 같이 해석한다. 컴포넌트를 변경하는 이유는 오직 하나뿐이어야 한다. 만약 컴포넌트를 변경할 이유가 한 가지라면 우리가 어떤 다른 이유로 소프트웨어를 변경하더라도 그 이유에 해당하지 않는 컴포넌트에 대해서는 신경쓸 필요가 없다. 변경할 이유라는 것은 컴포넌트 간의 의존성을 통해서 쉽게 전파가 된다. 컴포넌트간 의존성..
01. 계층형 아키텍처의 문제는 무엇일까? 일반적인 웹어플리케이션의 계층형 아키텍처 웹 -> 도메인(비즈니스) -> 영속성 잘 만들어진 계층형 아키텍처는 변화하는 요구사항과 외부 요인에 빠르게 적응할 수 있게 해준다. 계층형 아키텍처는 데이터베이스 주도 설계를 유도한다. 계층형 아키텍처에서 의존도 웹 -> 도메인, 도메인 -> 영속성 삼단논법에 의거해서 웹 -> 영속성 의존이라는 결론 도출! LIFIC 계층형 구조에서의 용어정리 웹 - 컨트롤러 도메인 - 서비스, 컴포넌트 영속성 - 리파지토리, 엔티티 영속성(데이터베이스)에 의존적인 계층형 아키텍처 실제로 개발하다보면 엔티티 의존적인 코드를 구현하고는 한다. 우리는 대체로 데이터베이스 모델링 -> 도메인 로직의 순서로 개발했을 것이다. 비지니스 관점에서..