Mono 0 또는 1개의 결과를 가지는 데이터 스트림 서블릿 스택에서의 Optional과 유사 Flux 0개 이상의 데이터 방출 서블릿 스택에서의 List와 유사 리액티브 스트림즈 핵심 컴포넌트 Publisher : 스트림 데이터를 생성/방출 subscriber에게 데이터 전달 Mono와 Flux도 Publsiher 타입 Subscriber : Publisher에 방출된 데이터를 처리 publisher에게 받은 데이터를 소비하거나 다른 작업 수행 가능, 백프레셔를 통해 데이터 흐름 조절 가능 subscription : Publisher와 Subscriber 간의 연결을 나타냄. Subscriber는 Subscription을 통해 Publisher의 데이터를 요청/취소 가능 Processor : Publi..

리액티브 프로그래밍 - 데이터가 변경될 때마다 이벤트를 발생시켜 데이터를 계속적으로 전달하는 것 - 실행할 동적을 구체적으로 명시하는 명령형 프로그래밍과 달리 단순히 목표(함수)를 선언 Webflux 비동기적인 웹 애플리케이션을 개발하기 위한 모듈 더 많은 동시 요청 처리, 더 빠른 응답 시간과 확장성 제공 reactor 반응형 스트림 라이브러리 기반 동작 동기 / 비동기 요청한 작업에 대해 완료 여부를 신경써서 작업을 순차적으로 수행하는지 여부 동기 : 다른 작업을 요청한 후 해당 작업이 완료되면 바로 해당 작업을 진행(완료가 되면 즉시 처리) 비동기 : 작업을 요청되고 완료를 기다리지 않고 다른 작업을 실행(한 작업이 완료되기를 기다리지 않고 다른 작업 실행, 완료가 되어도 즉시 처리하지 않음) 작업..

네 개의 영역 표현 영역 사용자 요청을 받아 응용 영역에 전달, 응용 영역의 처리 결과를 다시 사용자에게 전달 응용 영역 시스템이 사용자에게 제공해야할 기능을 구현 응용 서비스는 로직을 직접 수행하기보다는 도메인 모델에 로직 수행을 위임 도메인 모델 도메인 핵심 로직을 구현 인프라스트럭처 영역 구현 기술에 대한 것을 다룸 DB 연동, 메시징 큐 송수신 계층 구조 아키텍처 계층 구조는 상위 계층에서 하위 계층으로 의존만 존재 하위 계층은 상위 계층에 의존하지 않음 구현의 편리함을 위해 계층 구조를 유연하게 적용하기도 함 인프라 스트럭처에 의존하면 test와 기능 확장에 어려움을 가짐 : DIP로 해결 DIP 상위 모듈은 하위 모듈에 의존해서는 안 됨. 변하지 않는 것에 의존 -> 추상화에 의존 -> 인터페..

도메인이란? - 도메인 : SW로 해결하고자 하는 문제 영역 - 도메인은 여러 하위 도메인으로 구성됨. - 한 하위 도메인은 다른 하위 도메인과 연동하여 완전한 기능 제공 - 특정 도메인 위한 SW라고 해서 도메인이 제공해야 할 모든 기능을 직접 구현하지 않음. - 일부 기능은 자체 시스템으로 구현, 나머지 기능은 외부 시스템 사용 EX) 온라인 쇼핑몰은 외부 배송 업체의 시스템 사용. 필요한 기능만 일부 연동 도메인 전문가와 개발자 간 지식 공유 - 요구사항은 첫 단추와 같음. 코딩에 앞서 요구사항을 올바르게 이해하는 것이 중요. - 개발자와 전문가가 직접 대화하는게 베스트 - 이해관계자와 개발자도 도메인 지식을 갖춰야 - 잘못된 값이 들어가면 잘못된 결과가 나옴. 요구사항도 마찬가지 - 관련자가 요구..

# 객체지양 설계 내 상호 연관 관점 ## 개념 관점 설계는 도메인 안에서 존재하는 개념과 개념들 사이 관계를 표현 실제 도메인의 규칙 및 제약을 최대한 유사하게 반영 ## 명세 관점 사용자의 영역인 도메인을 벗어나 개발자의 영역인 SW에 초점이 옮겨짐 도메인에서 벗어나 실제 SW안에서 살아 숨쉬는 객체들의 책임에 초점 즉, 인터페이스를 바라봄 '무엇'을 할 수 있는가에 초점 ## 구현 관점 실제 작업을 수행하는 코드와 연관 객체들의 책임을 수행하는 데 필요한 동작하는 코드를 작성 '어떻게' 수행할 것인가에 초점 구현하지 않고 머리속으로만 구상한 설계는 코드로 구현하는 단계에서 대부분 변경됨. 설계 작업은 구현을 위한 스케치 를 작성하는 단계지 구현 그 자체일 수 없음. 중요한 것은 설계가 아니라 코드...

기능이 아니라 구조를 기반으로 모델을 구축하는 편이 좀 더 범용적이고 이해하기 쉬우며 변경에 안정적 # 기능 설계 VS 구조 설계 기능 설계 : 제품이 사용자를 위해 무엇을 할 수 있는가 구조 설계 : 제품의 형태가 어떠해야 하는가 훌륭한 기능은 충분조건, 훌륭한 구조는 필요조건 우리는 미래를 예측할 수 없다, 단지 대비할 수 있을 뿐 훌륭한 SW는 좋은 기능을 제공하면서 변경에 유연 좋은 설계는 병결할 수 있는 여지를 남겨 놓는 설계 변경의 여지를 남겨 놓는 가장 좋은 방법은 자주 변경되는 기능이 아닌 안정적인 구조를 중심으로 설계하는 것 # 객체지향 설계 기법 구조는 사용자나 이해관계자들이 도메인에 관해 생각하는 개념과 개념들 간의 관계로 표현 : 도메인 모델링 기능은 사용자의 목표를 만족시키기 위해..