쵸코쿠키의 연습장

어떤 종류의 프론트 웹 개발을 수행했다면 웹 사이트를 개발할 때 jQuery가 얻을 수있는 이점을 이해할 수 있습니다. jQuery의 가장 큰 장점 중 하나는 모든 브라우저에서 동일하게 수행되므로 최신 버전의 크롬에서 수행하는 모든 작업은 IE에서 동일하게 작동한다는 것입니다. jQuery로 수행하는 모든 작업이 다른 브라우저에서 작동한다는 것을 알고 있으므로 이는 jQuery 애니메이션 작업시 큰 이점입니다. JSON 또는 XML jQuery로 작업하더라도 다른 브라우저에서 작업하기가 매우 쉽습니다. 최근 jQuery 블로그에서 jQuery 버전 2에서는 IE8 이하를 지원하지 않을 것이라고 발표했습니다. jQuery 2.0 (2013 년 초, 1.9 이후) : 이 버전은 jQuery 1.9와 동일한 ..

SOAP SOAP은 웹서비스 간에 교환되는 메시지의 packaging과 전송을 위한 표준 프레임워크로서 두 가지 정의가 있습니다. 첫 번째 정의는 service oriented architecture protocol이라는 정의입니다. SOAR을 이루는 서비스의 인터페이스를 정의하고 이에 따라서 서비스 간의 정보를 교환하는 프로토콜을 의미합니다. 두 번째 정의는 RPC 모델을 기반으로 서비스를 원격으로 호출합니다. 이때 필요로 하는 메시지를 marshaling, unmarshaling하기 위한 프로토콜이라는 정의가 있습니다. 이러한 SOAP 메시지는 네 개의 요소로 구성이 되어 있습니다. 먼저 전체 SOAP 메시지는 SOAP envelope이라는 것으로 감싸져서 전송이 됩니다. 그 SOAP envelope..

은행 도메인 먼저 SOA를 적용해서 어떤 비즈니스 Goal을 달성하고자 하는지를 설정해야 합니다. 금융 도메인을 보면 다양한 비즈니스 라인에서 다양한 서비스가 제공되어야 합니다. 또한 다양한 채널을 통해서 고객들이 그러한 서비스를 소비해야 됩니다. 그래서 이 경우에서는 비즈니스 Goal로서 새로운 비즈니스 환경에서 어떻게 하면 혁신을 이루고 또한 투자 대비 효과를 빠르게 할 수 있을까 하는 것을 목표로 설정합니다. 또한 금융권을 보면 은행이 빈번하게 서로 합병을 하게 됩니다. 이러한 경우에 기존에 은행들이 사용하고 있던 서로 다른 금융 시스템들이 기존의 사용자들에게 제공되는 서비스의 중단 없이 효과적으로 통합되는 것이 굉장히 중요합니다. 그래서 SOA를 적용할 때를 이러한 문제 해결을 목표로 설정할 수 ..

웹 서비스란 무엇인가? 기능들을 API(Application Programming Interface)로 제공을 해서 프로그램에 직접 활용할 수 있는 것들을 웹 서비스라고 일반적으로 부릅니다. 그래서 웹 서비스는 전체적인 SOA의 구성 레이어에서 서비스 컴포넌트와 서비스 클라이언트 간의 Interaction이 웹 표준적인 인터페이스를 통해서 이루어집니다. 웹 서비스라는 것은 어떠한 표준적인 수단입니다. 즉, 서비스 간의 Interaction을 표준적인 수단을 통해서 하게 됩니다. 그런 것들을 통해서 애플리케이션을 개발할 수 있는 환경이 됩니다. 웹 서비스 디렉토리 이렇게 다양한 웹 서비스들이 웹에 존재합니다. 대표적인 웹 서비스 디렉토리, 웹 서비스를 찾을 수 있는 디렉토리 중에 하나가 programmab..

서비스 기반 아키텍처를 구성하는 목표 다양한 기존의 레거시 시스템, 이미 존재하고 있는 시스템들이 복잡하게 연결되어 있습니다. 어떠한 기업에서 이미 가지고 있는 다양한 시스템들이 있습니다. 이런 시스템들을 서로 상호작용하게 해서 또 다른 새로운 애플리케이션을 만듭니다. 이미 새롭게 개발된 시스템들이 있는데 그런 것들하고 어떻게 연동시킬지는 어려운 문제입니다. 그래서 서비스 기반 아키텍처를 구성하는 첫 번째 목표 중에 하나는 기존의 레거시 시스템들을 잘 활용해서 새로운 애플리케이션을 만들어내자는 목표입니다. 두 번째 중요한 목표는 기존에 기업에서 제공하는 다양한 서비스를 웹을 통해서 사용자들한테 노출하는, 사용자들이 사용할 수 있게 하는 목표가 있습니다. SOA를 사용하게 되면 기존에 기업에서 제공하던 여..

서비스의 기본 개념 MS Word는 직접 이 소프트웨어를 구매해서 설치를 해야 합니다. 또한 이러한 MS Word는 설치한 컴퓨터에서만 사용을 할 수 있습니다.그래서 Availability 차원에서 MS는 굉장히 제한적입니다. Google Docs는 인터넷만 연결돼 있으면 어떠한 컴퓨터에서든지 웹 브라우저를 통해서 접근할 수 있습니다. 또한 이렇게 설치가 필요 없는 Google Docs은 어떠한 컴퓨터든 상관없이 Operating System, Hardware 그런 플랫폼에 상관없이 사용할 수 있는 특징이 있습니다. 또한 새로운 소프트웨어 버전이 나왔다든지 문제를 해결하는 패치가 나왔을 경우에 MS Word는 설치를 해야 됩니다. Google Docs 같은 경우는 언제나 접속만 하면 최신의 소프트웨어를 ..

아키텍처의 평가 절차 첫째 단계는 평가방법 준비 단계로 이 단계에서는 아키텍처 평가 방법을 결정합니다. 둘째 단계에서는 아키텍처와 아키텍처 분석관점을 사용하여 분석을 수행하고 분석결과를 얻습니다. 분석결과는 아키텍처 설계를 통하여 이미 도출되어 있는 경우 이를 사용하면 됩니다. 그 렇지 않은 경우는 새로이 분석을 수행하여야 합니다. 마지막 단계에서는 단계2로부터 얻어진 분석결과에 대하여 단계1에서 결정된 종합 방법을 적용하여 평가결과를 얻습니다. CBAM CBAM 절차는 아키텍처 설계의 방향을 결정하는 아키텍처 전략들과 분석관점을 형성하는 N개의 품질속성 시나리오를 입력으로 하여 평가를 수행하고 평가결과로 각 아키텍처 전략의 순위를 결정합니다. CBAM은 비용과 이득 관점의 계량적 분석 방법으로 합리적인..

엔티티 / 애그리게잇 이 entity라는 것은 이벤트 수행 결과를 표현하는 데이터, 저장하는 데이터입니다. 이 entity aggregate 이름은 노란색 스티커에 작성해서 command과 도메인 이벤트 짝의 위쪽에 살짝 겹치도록 붙이게 됩니다. 이렇게 command, 도메인 이벤트에서 entity aggregate을 찾는 동안 새로운 도메인 이벤트를 발견할 수 있습니다. 이런 경우도 발견하는 즉시 모델링 공간 내의 흐름에 맞는 위치에 작성해서 붙이면 됩니다. change account command와 account changed 도메인 이벤트의 account에 대한 변경 요청과 변경이 수행되었다는 이벤트의 짝으로 account로 작성해서 붙일 수 있습니다. 마찬가지로 request purchase와 p..

이벤트 스토밍 이벤트 스토밍은 도메인 이벤트를 찾는 활동으로 시작을 했습니다. 도메인 이벤트를 동작하게 하는 command를 찾는 활동에 대해 알아보겠습니다. 커맨드 command는 도메인 이벤트를 발생시키는, 즉 도메인 이벤트를 동작하게 하는 명령입니다. 이 command의 이름은 change account, request shipment와 같이 명령어의 형태로 작성을 합니다. 찾은 command의 이름은 파란색 스티커에 작성을 해서 이 command과 연관된 도메인 이벤트의 왼쪽에 붙입니다. account changed라는 도메인 이벤트를 동작하게 하는 만드는 command으로 change account를 적어서 account changed 스티커의 왼쪽에 붙입니다. 이 방법으로 account reg..

쇼핑몰 서비스 이 쇼핑몰 서비스는 상품을 판매하는 사람과 구매하는 사람을 이어주는 서비스입니다. 이 서비스는 판매자가 상품을 온라인으로 팔기 위해 쇼핑몰 서비스에 상품을 등록합니다. 이 상품이 필요한 사람이 상품을 주문하면 판매자는 구매한 사람에게 상품을 배송합니다. 이후 구매자가 상품을 받으면 구매를 확정하는 일반적인 쇼핑몰 서비스입니다. 이 서비스의 사용자는 상품 판매자와 상품 구매자로, 상품 판매자는 판매하고자 하는 상품을 쇼핑몰 서비스에 등록합니다. 판매가 된 상품을 구매자에게 발송하는 업무 그리고 상품 구매자는 상품 판매자가 등록해놓은 상품을 구매합니다. 상품이 도착하면 최종 구매를 완료하게 됩니다. 이벤트 스토밍은 도메인의 이벤트를 찾는 것으로부터 시작합니다. 이 도메인 이벤트를 찾을 때에는 ..

전략적 설계 설계를 진행하면서 계속해서 개념들이 쌓여 설계가 점점 커지게 되면 중요한 것과 덜 중요한 것들을 찾아서 분할을 해야합니다. 소프트웨어를 개발하려고 하는 큰 도메인을 논리적으로 분리해서 핵심, 지원, 일반 서브도메인으로 나눕니다. 서브도메인에서 바운디드 텍스트를 도출하게 되는데 이때 서브도메인과 바운디드 컨텍스트는 1:1 또는 1:N으로 도출이 될 수 있습니다. 이렇게 찾아진 컨텍스트들 간의 관계를 찾아 컨텍스트 맵을 그릴 수 있습니다. 최종적으로 마이크로서비스를 도출할 수 있습니다. 효과적인 설계에 대한 요구 소프트웨어의 전반적인 목적은 특정 도메인의 일이 더 잘 동작하도록 하는 데 있습니다. 따라서 소프트웨어는 도메인을 정확히 구현해야 된다고 말씀을 드릴 수 있습니다. 도메인 주도 설계는 ..

도메인 모델의 표준 패턴 다이어그램과 같은 도메인 모델을 그리기 위해서 알아야 될 도메인 모델의 표준 패턴에 대해 알아보도록 하겠습니다. 전술적 설계를 위한 모델 주도 설계의 내비게이션 맵으로 도메인 모델을 위해 사용하는 표준 패턴과 각 패턴과의 관계를 나타낸 그림입니다. 이런 표준 패턴을 사용해서 도메인 모델링을 하게 되면 다른 사람의 업무, 다른 팀의 업무를 쉽게 이해할 수 있는 설계의 체계를 가져갈 수 있습니다. 따라서 훌륭한 도메인 모델을 개발하기 위해 화면과 같은 표준 패턴에 대해 이해를 하고 있어야 됩니다. 계층형 아키텍처와 도메인 모델의 표준 패턴, 도메인을 표현하기 위한 표준 패턴 중 전술적 설계에서 반드시 이해해야 되는 패턴들이 있습니다. 계층형 아키텍처 소프트웨어를 만들 때 개발되는 시..

컨텍스트 매핑 여러 개의 Bounded Context들은 비즈니스의 문제 해결을 위해 상호 간에 연동이 필요하게 되됩니다. 이런 경우 두 Bounded Context 사이에 선을 그려서 두 Bounded Context가 관계를 갖고 있다는 것을 표시합니다. 서로 다른 Bounded Context를 담당하는 팀에서는 각각의 유비쿼터스 언어를 정의해서 사용하게 됩니다. 이 선은 두 Bounded Context가 갖고 있는 각각의 유비쿼터스 언어 사이의 통역, 번역을 의미한다고 할 수 있습니다. Bounded Context 사이의 관계를 찾아 매핑할 때 두 Bounded Context 사이의 선이 어떤 종류의 관계인지를 찾는 것이 매우 중요합니다. 두 영역 간의 경계와 그 사이의 관계를 잘 정의합니다. 시간에..

도메인 주도 설계 소프트웨어에서 효과적인 설계는 매우 중요합니다. 도메인 주도 설계에서는 설계를 효과적으로 수행할 수 있도록 마이크로서비스를 식별해내는 전략적 설계와 식별된 마이크로서비스의 내부를 상세히 설계하는 전술적 설계로 설계를 두 개의 단계로 설명하고 있습니다. 상세한 설계에 들어가기에 앞서 전략적 설계를 수행합니다. 전략적 설계는 마이크로서비스 도출을 위해서 비즈니스 상 전략적으로 중요한 것을 찾아 중요도에 따라 이를 나누는 방법을 설명하고 있습니다. 전략적 설계 이런 전략적 설계를 수행하기 위해 중요한 두 가지가 있는데, 첫 번째는 도메인의 주요 개념을 정의하고 도메인 간의 경계를 식별하는 Bounded Context가 있습니다. 그리고 두 번째는 프로젝트를 수행하는 모든 팀원이 공통으로 사용..

소프트웨어 본질 소프트웨어 본질은 해당 소프트웨어 사용자들을 위해 복잡한 도메인에 관련된 문제들을 해결하는 데 있습니다. 복잡한 도메인을 소프트웨어로 구현하기 위해서는 해당 도메인을 바르게 이해해야 되는데, 도메인 전문가와 개발자 등 프로젝트에 참여한 모든 구성원들은 도메인의 올바른 이해를 위해 많은 노력을 해야 됩니다. 그러나 보통의 프로젝트에서는 비용과 일정, 인력 등 리소스 관리를 중요시하고 있습니다. 특히 개발자들도 도메인에 대한 이해보다는 UI, Framework, DB 등 최신 기술을 습득하고 적용하는 것에만 관심이 많은 것이 사실입니다. 그러므로 도메인의 문제를 해결할 수 있는 올바른 소프트웨어를 개발하기 위한 도메인 주도 설계에 대해 알아보겠습니다. 도메인 주도 설계 도메인이란 비즈니스나 ..

아키텍처 분석과 평가의 정의 아키텍처 분석과 평가라는 용어에 대하여는 표준화된 정의가 존재하지 않습니다. 분석과 평가를 구별 없이 사용하는 경우도 많습니다. 그러나 분석과 평가는 밀접히 관련된 서로 구별되는 개념입니다. 분석은 전체를 그것을 구성하는 부분들로 분리하는 활동으로 물체를 구성하는 요소들을 식별하거나 분리하는 활동, 즉 복합체와 그 요소들 및 그 관계를 상세히 검사하는 활동을 의미합니다. 평가는 가치를 판단하거나 결정하는 활동으로 신중한 조사 학습을 통하여 중요성, 가치 혹은 상태를 판단하는 활동을 의미합니다. 분석은 분해하여 들여다보는 활동이고, 분석을 위해서는 분석관점이 필요하며, 분석은 판단/평가를 위한 원시 데이터를 제공합니다. 반면 평가는 분석의 결과를 종합하여 판단하는 활동이며, 원..

도메인 주도 설계 가변적인 클라우드 인프라 위의 어플리케이션인 마이크로서비스는 그 아키텍처에 특히 유연성과 확장성을 강조하고 있습니다. 이벤트 주도 설계를 통해서도 살펴보았지만 서비스를 제공하는 각 서비스 간의 관계는 서비스가 독립적입니다. 대체가능하도록 느슨하고 유연하게 구조화되어 있어야 합니다. 또한 헥사고날 아키텍처를 통해 살펴본 것처럼 서비스 내부의 구조도 시스템의 유연성과 확장성을 높여야 합니다. 그러기 위해 기술과 비즈니스 로직을 분리하여 구축하는 것이 바람직합니다. 어떻게 각각의 서비스를 비즈니스 독립적으로 식별할 수 있냐는 것과 또 하나는 서비스 내부 구조화 측면에서 어떻게 기술과 독립된 비즈 모델을 잘 설계할 수 있느냐 하는 질문이 있습니다. 이러한 질문에 답을 주는 아주 유용한 도구가 ..

std::shared_ptr 강한 참조 기반입니다. 강한 참조 카운트를 늘려줍니다. 직접적으로 사용할 수 있습니다. 원시 포인터가 확실히 존재하기 때문입니다. std::weak_ptr 약한 참조 기반입니다. 약한 참조 카운트를 늘려줍니다. 직접적으로 사용할 수 없습니다. lock을 써서 std::shared_ptr가 여전히 존재하는 지 확인해야 합니다. 예제 #pragma once #include #include #include #include #include "MyVector2D.h" using namespace std; namespace samples { class SimpleCache { public: SimpleCache() = default; ~SimpleCache() = default; voi..

CQRS(Command Query Responsibility Segregation : 명령 조회 책임 분리 서비스의 성능향상을 위해 서비스 Instance를 Scale Out하여 여러 개로 실행한 경우에 데이터 읽기/업데이트 작업으로 인한 리소스 교착 상태가 발생할 수가 있습니다. CQRS 패턴이라고 합니다. Command Query Responsibility Segregation, 명령 조회 책임 분리 패턴입니다. CQRS는 기존의 일반적인 개념이었던 동일한 저장소에 데이터를 넣고, 입력/수정/삭제/조회하는 방식에 도전하는 흥미로운 패러다임을 도입하고 있습니다. 일반적으로 사용자의 비즈니스 요청은 시스템 상태를 변경하는 명령과 시스템의 상태를 가져오는 조회의 두 부분으로 크게 나눌 수 있습니다. 사실 ..

약한 참조 약한 참조는 원시 포인터 해제에 영향을 끼치지 않습니다. 약한 참조 카운트는 약한 참조의 수를 저장하는 데 사용됩니다. 약한 참조로 참조되는 개체는 강한 참조 카운트가 0이 될 때 소멸됩니다. 순환 참조 문제의 해결책입니다. #include #include "Persion.h" int main() { std::shared_ptr owner = std::make_shared("pp"); std::weak_ptr weakOwner = owner; return 0; } 약한 포인터로 공유 포인터 만들기 #include #include "Persion.h" int main() { std::shared_ptr owner = std::make_shared("pp"); std::weak_ptr weakOw..