StarLord

배치가 단순히 Fetch From Source > Data CUD > Data Write 이런 프로세스라면 어려울 것도 없다. 데이터가 많은 금융, 산업 쪽은 배치가 무지무지 복잡하다... 배치가 복잡해지는 이유는 다음의 요소들이 흐름에 끼어있기 때문이다. 1. FETCH할 SOURCE가 여러개 2. DATA WRITE할 DESTINATION이 여러개 - 병렬 WRITE - 분기 WRITE 3. FETCH DATA의 FILTERING을 통한 다이어트 4. DATA 가공 과정에서 분기 - 단순 분기 - 동적 조건에 따른 분기 이런 요소들로 인해서 복잡한데 이걸 극복하는 컨셉은 크게 두가지가 있다. 가. Spring Batch의 Object를 써서 극복할 것인지 나. JAVA와 SQL로 극복할 것인지 가. ..

오류 /usr/include/c++/4.8.2/bits/c++0x_warning.h:32:2: error: #error This file requires compiler and library support for the ISO C++ 2011 standard. This support is currently experimental, and must be enabled with the -std=c++11 or -std=gnu++11 compiler options. 해결방안 # yum -y install centos-release-scl # yum -y install devtoolset-7 # scl enable devtoolset-7 bash 위 내용 미적용 시 에러 발생 :

모든 개체에는 수명 주기가 있습니다. 객체는 생성되고 다양한 상태를 거치며 결국 아카이브되거나 삭제되어 죽습니다. 물론 이들 중 다수는 생성자를 쉽게 호출하여 생성되고 일부 계산에 사용된 다음 가비지 수집기에 버려지는 단순하고 일시적인 개체입니다. 그러한 개체를 복잡하게 만들 필요가 없습니다. 그러나 다른 개체는 수명이 더 길며 모든 개체가 활성 메모리에서 소비되는 것은 아닙니다. 그들은 다른 객체와 복잡한 상호 의존성을 가지고 있습니다. 그것들은 불변이 적용되는 상태 변경을 거칩니다. 이러한 개체를 관리하는 것은 MODEL-DRIVEN DESIGN 시도를 쉽게 탈선시킬 수 있는 Challenge를 야기합니다. Challenge는 두 가지 범주로 나뉩니다. 1. 라이프 사이클 전반에 걸쳐 무결성 유지 2..

결합 가능한 한 관계를 제한하는 것이 중요합니다. 양방향 결합은 두 객체가 함께있어야만 이해될 수 있음을 의미합니다. 응용 프로그램 요구 사항이 양방향 순회를 요구하지 않는 경우 순회 방향을 추가하면 상호 의존성이 줄어들고 설계가 단순화됩니다. 도메인을 이해하면 자연스럽게 방향성을 알수 있습니다. 미국에는 다른 많은 국가와 마찬가지로 많은 대통령이 있습니다. 이것은 양방향, 일대다 관계입니다. 그러나 우리는 "조지 워싱턴"이라는 이름으로 시작하여 "그는 어느 나라의 대통령이었습니까?"라고 묻는 경우는 거의 없습니다. 실용적으로 우리는 "국가"에서 "대통령"으로 이동하는 단방향 연결 관계를 줄일 수 있습니다. 이 개선은 실제로 도메인에 대한 통찰력을 반영할 뿐만 아니라 보다 실용적인 디자인을 만듭니다. 그..

객체 지향 프로그램에서 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..

어느분께서 알려주셔서 찾아보았다. 리액티브 프로그래밍 모델 이란? Keyword : 반응형(이벤트Driven), 비동기(Non-Blocking), BackPressure(안전장치) 반응형 : 리액티브로 짜여진 어플리케이션은 탄력적으로 worker thread가 반응할 뿐만아니라 worker thread가 레거시 방식보다 더많이 늘어날 수 있다. 이는 각 worker thread가 상호의존성이 없어 tied up하지 않기 때문이다. 마치 Nginx와 Apache의 아키텍처 차이와 같은 느낌.. 비동기 : Thread A가 Thread B를 참조할 경우 Thread A는 Thread B의 Return을 대기하지 않는다. Thread는 각자 자기 할일을 하는것 BackPressure : Message(Comm..

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