아키텍처 (4) 썸네일형 리스트형 헥사고날 아키텍처 정리 및 예제 일반적인 계층화 아키텍처의 문제점 저 같은 경우 예전에는 습관적으로 Controller, Service, Repository를 작성하고, 이것을 표현(프레젠테이션) 계층, 비즈니스 로직 계층, 영속화(퍼시스턴스) 계층이라고 생각하고 사용했습니다. 하지만 일반적인 계층화 아키텍처에는 몇 가지 중요한 이슈가 있다고 생각합니다. 표현 계층은 하나뿐인가? 사실 애플리케이션을 호출하는 시스템은 다양할 수 있습니다. 자주 사용되는 HTTP 호출이 있을 수 있고, 또는 웹소켓을 통한 호출 및 기타 다양한 프로토콜이 될 수 있습니다. 영속화 계층이 하나뿐인가? 표현 계층에 대한 문제와 유사합니다. 사용하는 DB가 MySQL, Oracle과 같은 RDBMS일수도 있고, 빠른 검색 및 샤딩을 위한 NoSQL이 될 수 있.. 데이터베이스와 아키텍쳐 구성 데이터베이스와 아키텍쳐 구성 DB 서버의 다중화 - 클러스터링 클러스터링이 어려운 컴포넌트로 인식 데이터를 보존하는 '영속 계층' 이기 때문 '데이터의 정합성이 중요하기 때문' 가장 기본적인 다중화 DB 서버 N, 저장소 1 Active-Active : 클러스터를 구성하는 컴포넌트를 동시에 가동 Active-Standby : 클러스터를 구성하는 컴포넌트 중 실제 가동하는 것은 Active, 남은 것은 대기하고 있는다. Active-Active 구성의 장단점 시스템이 다운되어 있는 시간이 짧다 복수의 DB 서버가 동시에 작동하고 있어서 한 대가 다운되어 동작 불능이 되어도 남은 서버가 처리를 계속하기 떄문에 시스템 전체가 정지하는 것을 방지할 수 있음 성능이 좋다 동시에 가동하.. [레거시 코드 활용 전략] CH3 감지와 분리 2020/02/03 - [IT/책읽는 개발자] - [레거시 코드 활용 전략] CH1 소프트웨어 변경 2020/02/04 - [IT/책읽는 개발자] - [레거시 코드 활용 전략] CH2 피드백 활용 ch 3 - 감지와 분리 이상적인 환경이라면 변경 작업을 하기 전 특별히 할 일이 없다. 테스트를 하고 싶은 대상을 테스트 코드 내에서 객체를 생성해 작업을 하면 끝이다. 하지만 불행하게도 클래스들의 의존 관계들 때문에 이것은 거의 불가능하다. 의존관계를 제거해야 하는 이유는 무엇일까? 크게 두 가지로 볼 수 있다. 감지 : 코드 내에서 계산된 값에 접근하여 변경이나 값을 확인할 수 없을 때 분리 : 코드를 테스트 코드 내에서 실행할 수 없을 때 코드 분리를 위해 예제 코드 public class Network.. [레거시 코드 활용 전략] CH2 피드백 활용 이전글 : 2020/02/03 - [IT/책읽는 개발자] - [레거시 코드 활용 전략] CH1 소프트웨어 변경 ch 2 - 피드백 활용 시스템을 변경하는 방법에는 크게 두가지가 있다. 수정 후 기도하기 보호 후 수정하기 일반적인 개발 방법에서는 1번이 많이 사용된다. 1번 같은 경우 코드 변경 대상 코드를 이해하고, 계획을 세운 후 변경 작업에 들어간다. 변경을 완료하고 나서는 제대로 동작하고, 의도하지 않는 영향이 있는지 조사한다. 결과적으로 작업 결과를 확인하고 검토하는 시간이 추가로 들어가게 된다. 얼핏 보기에는 이는 매우 '신중'하고 '전문'적인 방식처럼 보인다. 그러나 아무리 신중해도 이것이 안전성에 비례한다는 보장은 없다. '보호 후 수정하기' 방법은 조금 다른 방식으로 코드를 변경한다. 변경.. 이전 1 다음
