쵸코쿠키의 연습장

전략적 설계 설계를 진행하면서 계속해서 개념들이 쌓여 설계가 점점 커지게 되면 중요한 것과 덜 중요한 것들을 찾아서 분할을 해야합니다. 소프트웨어를 개발하려고 하는 큰 도메인을 논리적으로 분리해서 핵심, 지원, 일반 서브도메인으로 나눕니다. 서브도메인에서 바운디드 텍스트를 도출하게 되는데 이때 서브도메인과 바운디드 컨텍스트는 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..

서비스별 데이터베이스 Soa와 구분되는 Msa 특징으로 각각의 마이크로서비스는 각자의 비즈니스 처리를 위한 영구 데이터를 소유하고 있다는 것입니다. 그렇기 때문에 이러한 소유한 데이터는 다른 서비스에 직접 호출되게 하지 않고, 자신의 API를 통해서만 액세스 할 수 있습니다. 주문서비스가 주문수행을 위해 고객 정보를 필요로 한다면, 바로 고객 테이블을 질의를 할 수 없습니다. 반드시 고객 서비스의 API를 통해서만 호출할 수 있습니다. 따라서 이런 구조에서 분산 트랜잭션 문제가 발생할 수 있습니다. 여러 서비스 간에 데이터 일관성을 유지하는 방법 두 개의 서비스에 걸쳐서 트랜잭션 처리가 필요한 업무가 있을 수 있습니다. 즉 여러 서비스 간의 데이터 일관성을 유지할 필요가 있습니다. 이런 분산 트랜잭션 처..

std::shared_ptr #include #include"Vector.h" int main() { std::shared_ptr vector = std::maked_shared(10.f, 30.f); // ... } 두개의 포인터를 소유합니다. 데이터를 가리키는 포인터와 제어 블록을 가리키는 포인터입니다. std::unique_ptr와 달리, 포인터를 다른 std::shared_ptr와 공유할 수 있습니다. 참조 카운팅 기반이라 할 수 있습니다. 원시 포인터는 어떠한 std::shared_ptr에게도 참조되지 않을 때 소멸됩니다. 포인터 재설정하기 std::shared_ptr vector = std::maked_shared(10.f, 30.f); std::shared_ptr copiedVector = ..

마이크로 서비스 통신 방법 Rest API는 클라이언트에서 서버 쪽에 존재하는 마이크로서비스를 호출할 때 기본 통신방법이 되며, 다양한 클라이언트 채널 연계나 외부에 API의 공개를 원활하게 하기 위한 방법으로는 API G/W를 사용하는 것을 살펴봤습니다. 제일 먼저 검토해야 할 방법은 Rest API 같은 동기식 호출입니다. Sync 방식이라고도 합니다. 동기식 호출은 Request를 하면 바로 Response가 오는 방식을 말합니다.모바일 UI에서 상품서비스에 Post 방식의 요청을 하고, 상품은 주문 서비스에 Get 방식의 동기호출을 하고 있습니다. 그에 따라 바로 응답이 발생하고, 200이라는 OK 코드도 받아오는 것을 볼 수 있습니다. 바로 요청하면 응답이 오는 패턴이기 때문에 가장 많이 쓰이는..

자동 메모리 관리 std::shared_ptr를 배우기 전에, 자동 메모리 관리에 관해 알아야 합니다. 주로 쓰는 두가지 기법이 있었습니다. 첫번째는 가비지 컬렉션이고, 두번째는 참조 카운팅이 있습니다. 가비지컬렉션은 Java와 C#에서 활용되고 있으며, 참조 카운팅은 Swift와 오브젝트 C에서 지원됩니다. 가비지 컬렉션 보통 트레이싱 가비지 컬렉션을 의미합니다. 메모리 누수를 막으려는 시도에서 나오게 되었습니다. 주기적으로 컬렉션을 실행합니다. 충분한 여유 메모리가 없을 때 컬렉션이 실행됩니다. 스케쥴에 따라 또는 수동으로도 실행 가능합니다. 매 주기마다 GC는 루트를 확인합니다. 즉, 전역 변수, 스택, 레지스터들을 확인합니다. 힙에 있는 개체에 루트를 통해 접근할 수 있는 지 판단합니다. 접근할 ..

Presentation Layer Presentation Layer에서 가장 많이 쓰이는 패턴은 Model View Controller로 이루어진 MVC 패턴입니다. MVC 모델은 초기 컨트롤러와 모델이 어떤 기술을 쓰느냐에 따라 발전해왔습니다. 최근에는 JSP가 View의 역할을, POJO가 모델의 역할, 서블릿이 이 두 개의 요소를 연계하는 컨트롤러의 역할을 수행하는 방식으로 발전해왔습니다. 그렇지만 현재는 JSP 서블릿뿐만 아니라 웹, 모바일, 태블릿, 인터넷, PC, 셋톱박스와 같은 다양한 인터페이스의 등장으로 인해서 이를 지원하기 위한 다양한 화면 플랫폼이 등장했습니다. Spring의 Thymeleaf나 페이스북이 공개한 React, 기존에 유명했던 ANGULARJS, 그리고 Vue.js 등의 ..

std::unique_ptr 포인터 대신 아주 많이 활용되고 있습니다. 직접 메모리 관리하는 것 만큼 빠릅니다. Resource Acquisition is initialization 원칙에 잘 들어맞습니다. 자원 할당은 개체의 수명과 관련되어 있습니다. 생성자에서 new를 하고 소멸자에서 delete를 해주어야하는데 유니크 포인터 멤버 변수가 알아서 동작하여 줍니다. 따라서, 실수하기 어려우며, 다양한 곳에서 활용하여도 좋습니다. 예제 #include #include #include "UsingUniquePointersExample.h" #include "MyVector.h" using namespace std; namespace samples { void UsingUniquePointersExample..

Layer 간의 의존성 UI 클라이언트가 Presentation Layer를 이용하고, Presentation 층이 Business Logic 층을 호출하고, Business Logic 층이 Data Access 층을 호출하고, Data Access 층이 저장소를 접근하게 됩니다. 어플리케이션에서 모든 영역이 중요하겠지만 가장 핵심적인 부분은 아무래도 어플리케이션이 제공하는 주요 서비스의 업무 로직을 담고 있는 Business Logic 층입니다. Presentation 층과 Data Access 층은 기술 트렌드에 따라 다양하게 교체 변화 가능하나, 핵심 비즈니스 기능은 한 번 정의되면 잘 변경되지 않습니다. 따라서 시스템의 확장성과 유연성을 높이기 위해 Layered Architecture는 이러한 ..

reset() int main() { std::unique_ptr vector = std::make_unique(10.f, 30.f); vector.reset(new Vector(20.f, 40.f)); vector.reset(); } 이거 말고 nullptr를 써야할까? vector.reset(); vecotr = nullptr; 두 코드의 의미는 같습니다. nullptr가 reset() 보다 가독성이 더 좋습니다. reset()은 vector가 원시 포인터가 아님을 분명하게 보여줍니다. 따라서, 취향에 맞게 구현하여도 무방하다고 합니다. reset()은 결국 포인터를 교체하는 것을 의미합니다. std::unique_ptr가 재설정 될 떄, 소유하고 있던 원시 포인터는 자동으로 소멸됩니다. get() ..

Tier와 Layer Tier는 물리층을 의미하며, Layer는 논리층을 의미합니다. Tier는 물리적인 장비, 서버 컴퓨터가 될 수 있습니다. Layer는 이러한 Tier 내부의 논리적인 분할을 의미합니다. 1:1이 될 수도 있지만 Tier의 내부를 제공하는 기능 성격에 따라 논리적 구분을 할 수 있습니다. 여기 어플리케이션 서버라는 중간층은 세 가지 Layer로 구별될 수 있습니다. 가장 일반적인 어플리케이션 Layer인 Presentation, Business Logic, Data Access층으로 나눠질 수 있습니다. Layered Architecture Layered Architecture는 설계자들이 복잡한 시스템을 분리할 때 흔히 사용하는 패턴 중 하나로 상위는 하위를 호출하여, 상위는 하위..

스마트 포인터 - unique_ptr - shared_ptr - weak_ptr 예시: 포인터 #include "Vector.h" int main () { Vector* myVector = new Vector(10.f, 30.f); // delete myVector; return 0; } 항상 포인터를 생성하는 순간, delete를 구현해주어야 합니다. 하지만 프로그래머들이 가끔 실수를 할 수 있습니다. 더 이상 포인터가 필요하지 않을 때 메모리를 해제해야 합니다. 스마트 포인터를 쓰면 delete를 직접 호출할 필요가 없습니다. 그리고 가비지 컬렉션보다 빨라집니다. unique_ptr #include #include "Vector.h" int main() { std::unique_ptr myVector..