StarLord

객체 지향 프로그램에서 UI, 데이터베이스 및 기타 지원 코드는 종종 비즈니스 객체에 직접 작성됩니다. 추가 비즈니스 로직은 UI 위젯 및 데이터베이스 스크립트의 동작에 포함됩니다. 이것은 단기간에 작업을 수행하는 가장 쉬운 방법이기 때문에 발생하는 이슈 입니다. 도메인 관련 코드가 이렇게 많은 양의 다른 코드를 통해 확산되면 보고 추론하기가 매우 어려워집니다. UI에 대한 피상적인 변경은 실제로 비즈니스 로직을 변경할 수 있습니다. 비즈니스 규칙을 변경하려면 UI 코드, 데이터베이스 코드 또는 기타 프로그램 요소에 대한 세심한 추적이 필요할 수 있습니다. 일관된 모델 기반 개체를 구현하는 것은 비실용적입니다. 자동화된 테스트는 어색합니다. 각 활동에 관련된 모든 기술과 논리로 인해 프로그램은 매우 단순..

만약 소프트웨어 디자인이 도메인 모델과 매핑되지 않는다면, 그 모델은 가치가 없거나 소프트웨어의 정확성이 의심된다. 동시에 모델과 디자인 기능간의 매핑의 복잡성은 이해하기 어렵고 디자인 변경에 대한 유지관리가 어렵다. 분석과 디자인 사이에 치명적인 격차가 발생하여 각각의 활동으로 부터 얻은 인사이트가 서로 영향을 미치지 못하는 상태가 발생한다. MODEL-DRIVEN DESIGN은 해석 모델과 디자인의 이분법을 버리고 두 가지 목적을 모두 충족하는 단일 모델을 찾습니다. 순전히 기술적인 문제를 제외하고 디자인의 각 개체는 모델에 설명된 개념적 역할을 합니다. 이것은 두 개의 완전히 다른 목표를 충족해야 하기 때문에 우리에게 더 부담지우긴 합니다. 매핑이 명확하게 도메인 모델을 문자 그대로 소프트웨어 시스..

모델을 기반하는 커뮤니케이션은 UML과 같은 Diagram이 국한되어 하는 것이 아니다. 가장 효과적으로 모델을 사용하기 위해서 전달 방식을 스며들게 할 필요가 있다. 이것은 Text 문서의 활용성을 높일 뿐만아니라 에자일 프로세스에서 비형식적이고 캐쥬얼한 의사소통을 가능케한다. 이를 Ubiquitous Language라고 한다. 모델에 대한 설명의 비용, 오해의 리스크는 매우 높으므로 프로젝트에는 튼튼한 공통된 언어가 필요하다. 팀이 도메인 모델에 공을 많이 들이면 도메인 모델은 커뮤니케이션의 주측이 될 수 있다. 이것이 유비쿼터스 언어라고 할 수 있다. 초기 모델은 유비쿼터스 커뮤니케이션을 수용하기에는 부족한 수준으로 간결할 것이다. 해당 분야의 특정 용어에 대해서도 풍부하게 의미전달을 못할것이다. ..

개요 A domain model is not a particular diagram; it is the idea that the diagram is intended to convey. It is not just the knowledge in a domain expert’s head; it is a rigorously organized and selective abstraction of that knowledge. 도메인 모델이란 실질적인 다이어그램이 아니라 전달해야할 추상적인 다이어그램이다. 단지 도메인 전문가의 머릿속 지식에 그칠뿐만 아니라 엄격하게 "조직화"되고 "선별된" 지식이다. Knowledge Crunching 효과적인 domain 모델러는 지식을 잘 쪼개는 사람이다. Knowledge Crun..

한마디로 "Read와 CUD 트랜젝션을 분리할 수 있도록 어플리케이션 Model을 나누는 것" 기존의 무슨 문제가 있었나? 작업의 일부로 필요하지 않더라도 올바르게 업데이트해야 하는 추가 열 또는 속성과 같이 데이터의 읽기 및 쓰기 표현이 일치하지 않는 경우가 많습니다. 동일한 데이터 집합에서 작업을 병렬로 수행할 때 데이터 경합이 발생할 수 있습니다. 기존의 접근 방식은 데이터 저장소 및 데이터 액세스 계층의 로드와 정보를 검색하는 데 필요한 쿼리의 복잡성으로 인해 성능에 부정적인 영향을 미칠 수 있습니다. 보안 및 사용 권한 관리는 복잡해질 수 있습니다. 각 엔터티는 읽기 및 쓰기 작업이 모두 적용되므로 잘못된 컨텍스트에서 데이터를 노출할 수 있습니다. 어떤 효과가 발생하는가? 독립적인 크기 조정 :..

회복성을 결정하는데 있어서 다음의 요소가 있다. (회복성에 대한 이슈는 동기호출에서 많이 발생한다.) 그리고 구현기술/패턴은 다음과 같다. 1. 로드벨런싱(부하분산) → 일반적인 로드벨런서, Gateway, Ribbon 등 2. 회로차단기| 3. 폴백 4. 벌크헤드 → 서킷 브레이커 동기호출로 서비스를 구현하게 되었을 경우 특정 서비스의 트랜잭션이 지연되어 동기된 다른 서비스에도 지연현상이 전파될 수 있음. 이를 차단하기 위해 서킷브레이커 패턴을 적용 장애감지 시 차단기 작동 ▶ 일시적으로 Failback으로 서비스 대체 ▶ 일부 트래픽으로 서비스 정상여부 확인 ▶ 정상확인 시 차단기 해제

MSA 서비스를 분리한 후에는 어떻게 통합(상호연동, 객체참조)할 것인가? → API Gateway 역할 서비스 라우팅 CORS(교차출처) 허용 ACL 적용하여 잘못된 호출 필터링 기타 보안정책 적용(ex. Prevent DDOS) 로드벨런싱 관련도구 Proxy, Kube Gateway Service, [Zuul, Ribbon] → Service Registry+Service Discovery 역할 서비스 Discovery가 가능하도록 서비스 경로 저장 관련도구 Eureka, Kube DNS Service, 일반DNS서비스, Feign Client → URI Path-based Call (Req-Res) 역할 동기호출 관련도구 REST API → Message Queue Call (Pub-Sub) 역할 ..

어플리케이션 도메인의 변화 회사가 성장함에 따라 어플리케이션의 Core(중요한것)와 Supporting(덜 중요한것)으로 나누게 된다. 예시) Core - 사용자들은 주문하기 위해 많은 상품을 클릭하고 "구매" 버튼을 클릭 - 상품이 주문되면 배송팀은 상품의 배송을 준비 - 주문이 취소되거나 완료되면 상품재고 수치 감소 Supporting - 고객들은 매진된 상품을 구매할 수 있으며 이는 입고뒤 해소 - 배송 상태 변화시마다 Notification이 고객에게 전달 - 주문과 취소를 반복하는 고객은 블랙리스트로 관리 - 마케팅 팀은 매일 오전 9시에 추천상품을 메일링 회사가 더 규모가 성장하면 팀은 자치성과 동기부여를 위해 더 나뉘어 지게 된다. 예시) 배송관리팀 - 상품이 주문되면 배송팀은 상품의 배송을..

Micro Service Architecture 설계의 발전 1. Rest API 방식의 설계 (동기호출) - Code Coupling 해소. 그러나 Time Coupling 잔존 - 서비스 Blocking 가능성 내제 - 장애전파 우려 - Point to Point 연결에 따른 복잡한 스파게티 네트워크 Request-Response 모델의 데이타 보호 장애전파를 방지하기 위해 필요한것이 서킷브레이커 패턴. 하나의 트랜젝션이 가능한 블로킹이 발생하지 않도록 미리 차단 → Fail-Fast 전략 메모리 사용 폭주 막음 장애 감지시 차단기 작동 ▶ 일시 동안 Failback으로 서비스 대체 ▶ 일부 트래픽으로 서비스 정상여부 확인 ▶ 정상 확인 시 차단기 해제 Rest방식 MSA 에서도 모놀리식의 2단계 커..

AS-IS시스템의 Pain-Points는 다음의 것들이 있었다. 서비스 업그레이드가 수시로 요청이 들어와 거의 매일 야근 테넌트별 다형성 지원을 제대로 하지 못하여 가입 고객이 늘 때마다 전체 관리 비용이 급수로 올라가는 한계에 봉착 운영팀과 개발팀이 분리되어 개발팀의 반영을 운영팀이 거부하는 사례 발생 개발팀은 새로운 요건을 개발 했으나 반영하면서 발생하는 오류가 두려워 배포를 꺼려함 현재 미국, 일본, 유럽 등 수요가 늘어나는 상황이나 상기한 문제로 신규 고객의 요구사항을 받아들이지 못하는 상황 수동 운영의 문제로 SLA 준수가 되지 못하여 고객 클레임이 높은 편 기존 모놀리식 아키텍처의 한계로 장기적인 발전의 한계에 봉착 모놀리식의 장점 상호 데이터 참조가 용이하여 개발 리소스를 최소화 시킬 수 있..