Architecture4 [도메인주도설계 & 마이크로서비스] 1. 아마존 비즈니스 민첩성의 비밀 성공한 인터넷 기업들과 비즈니스 민첩성 아마존, 넷플릭스, 우버와 같은 기업들이 성공할 수 있었던 이유는 민첩성이라고 생각한다 비즈니스 민첩성은 어떻게 나타날까? 성공 사례 : 아마존의 배포 속도 먼저 아마존의 성공 사례를 살펴보자 아마존의 서비스 배포 주기는 11.6초라고 한다 비즈니스는 꾸준히 변경되므로 이에 따라 개선된 시스템도 계속 배포해야 한다 빠른 배포 주기는 비즈니스 민첩성을 간접적으로 보여주는 지표다 다른 예로 국내 한 쇼핑몰 시스템 배포 주기는 1주일이다 아마존 쇼핑몰은 전체 과정이 독립적으로 완료되어 초당 1.5번씩 변경, 개선되고 있다 긴급 배포를 포함하면 1주일에 3일정도로 생각할 수 있다 아마존과 비교하면 아마존 서비스는 0.66초마다 진화하고, 국내 쇼핑몰은 3일마다 진화하는 셈.. 2021. 9. 14. [Clean Architecture] 3. 설계원칙 - (3) OCP (개방-폐쇄 원칙) 개방 폐쇄 원칙(OCP)라는 용어는 1988년 버트란트 마이어가 만들었습니다 소프트웨어 개체는 확장에 열려 있어야 하고, 변경에는 닫혀 있어야 합니다 소프트웨어 아키텍처를 공부하는 가장 근본적인 이유가 바로 이 때문입니다 만약 요구사항을 살짝 확장하는 데 소프트웨어를 엄청나게 수정해야 한다면, 그 시스템 아키텍트는 엄청난 실패입니다 아키텍처를 공부하기 시작한 지 얼마 안된 사람들 대다수는 OCP를 클래스와 모듈을 설계할 때 도움되는 원칙이라고 알고 있습니다 하지만 아키텍처 컴포넌트 수준에서 OCP를 고려할 때 훨씬 중요한 의미를 가집니다 사고 실험 한 예를 통해 보도록 합시다 재무제표를 웹 페이지에 보여주는 시스템이 있습니다 웹 페이지에 표시되는 데이터는 스크롤할 수 있으며, 음수는 빨간색으로 출력합니다.. 2021. 9. 12. [Clean Architecture] 3. 설계원칙 - (2) SRP (단일 책임 원칙) 역사적으로 SRP는 아래와 같이 기술되어 왔습니다 단일 모듈은 변경의 이유가 하나, 오직 하나뿐이어야 한다 SRP를 정의는 아래처럼 말할 수 있습니다 하나의 모듈은 하나의, 오직 하나의 액터에 대해서만 책임져야 한다 (액터 : 해당 변경을 요청하는 한 명 이상의 사람들) (모듈: 소스파일) 징후 1 : 우발적 중복 Employee 클래스에 calculatePay(), reportHours(), save() 메소드를 가집니다 CFO, COO, CTO가 모두 이 클래스의 메소드를 사용합니다 현재 이 클래스는 SRP를 위반합니다 이 3가지 메서드가 서로 매우 다른 세 명의 액터를 책임지기 때문입니다 calculatePay()는 회계팀에서 기능을 정의하며, CFO 보고를 위해 사용합니다 reportHours().. 2021. 9. 12. [Clean Architecture] 3. 설계원칙 - (1) SOLID? 좋은 아키텍처를 정의하는 원칙은 SOLID 입니다 좋은 소프트웨어 시스템은 깔끔한 코드로부터 시작합니다 좋은 벽돌을 사용하지 않으면 빌딩 아키텍처가 좋고 나쁨은 그리 큰 의미가 없습니다 반대로 좋은 벽돌로 빌딩 아키텍처를 엉망으로 만들 수 있습니다 좋은 벽돌로 좋은 아키텍처를 정의하는 원칙은 SOLID 입니다 SOLID 원칙은 함수와 데이터 구조를 클래스로 배치하는 방법, 그리고 이들 클래스를 서로 결합하는 방법을 설명해줍니다 SOLID 원칙의 목적은 중간 수준의 소프트웨어 구조가 아래와 같도록 만드는데 있습니다 (중간 수준 : 프로그래머가 이들 원칙을 모듈 수준에서 작업할 때 적용할 수 있다는 뜻) 변경에 유연하다 이해하기 쉽다 많은 소프트웨어 시스템에 사용될 수 있는 컴포넌트 기반이 된다 SOLID .. 2021. 9. 5. 이전 1 다음
