설계9 DDD - 개념적 윤곽 - 출처: 도메인 주도 설계 - 에릭 에반스 - 개념적 윤곽(Conceptual contour) 코드를 개발하다보면 유연하게 조합할 수 있도록 작은 크기로 기능을 나누기도 하며, 복잡성을 캡슐화하기 위해 기능을 더 큰 단위로 통합 하기도 한다. 이런 방법들은 지나치게 단순해서 일반 원칙으로 적용하기에는 부적절하다. 하지마 이런 방법들은 문제를 해결하기 위한 동기를 부여한다. 모델 혹은 설계를 구성하는 요소가 모놀리식 구조이면 기능이 중복되어 클라이언트는 인터페이스로부터 유용한 정보를 일부만 파악가능하다. 반대로 클래스와 메소드를 잘게 나누면 작은 객체들의 협력 방식을 이해하고 있어야 하기 때문에 클라이언트 객체가 무의미하게 복잡해진다. 도메인에는 잠재적인 일관성이 존재한다. 특정 모델을 발견하면 나중에 .. 2022. 10. 31. DDD - Side effect free function - 출처: 도메인 주도 설계 - 에릭 에반스 - 연산과 함수 연산은 명령(command, modification)과 질의(query)로 나눌 수 있다. 명령(command, modification): 변수값을 변경해서 시스템의 상태를 변경 질의(query): 변수안에 저장된 데이터에 접근하고, 저장된 데이터를 기반으로 계산을 수행 함수는 부수효과를 일으키지 않고 결과를 반환하는 연산이다. 여러번 호출 해도 무방하며 매번 동일한 값을 반환한다. - 명령과 질의의 분리 명령과 질의는 서로 엄격하게 다른 연산으로 분리해야 한다. 변경을 발생시키는 메서드는 도메인 데이터를 반환하지 않고 단순하게 유지해야 한다. 또는 명령과 질의를 분리하는 대신 연산의 결과를 표현하는 새로운 VO(Value-Object)를 생성.. 2022. 10. 22. 아키텍처 - 아키텍처 사고 - 출처: 이 글은 도서 '소프트트웨어 아키텍처 101'을 참조하여 작성된글입니다. - 개요 아키텍처 사고는 단순히 '아키텍처를 생각하는것'이라고 많은 오해를 하지만 아키텍처 관점에서 사물을 바라볼줄 알아야 하는것을 의미한다. 아키텍트의 사고방식은 크게 4가지 사고방식으로 나눌 수 있다. 아키텍처와 설계 차이의 이해 기술의 깊이보다는 폭넓은 지식의 이해 다양한 솔루션과 기술간의 Trade off 이해 비즈니스 동인(행동을 촉발시키는 내적 원인의 총칭)의 중요성이해(이 글에서는 다루지 않는다.) - 아키텍처 vs 설계 아키텍처와 설계의 차이점은 모호한 경우가 많다. 이를 이해하기 위해 전통적인(기존 시각의) 아키텍트와 개발자의 책임을 이해해보자. 아키텍트 비즈니스 요구사항을 분석하여 아키텍처의 특성(~성).. 2022. 3. 9. [React 공식 Doc 가이드 #12] Thinking in React - 이 글은 React 공식 홈페이지 Docs v16.8.3 (https://reactjs.org/docs) 에 기반하여 작성한 글입니다. - Thinking in React React는 JavaScript 를 사용하는 대규모 Web app 일 빌드하고, 빠른 Web app 을 만들기 위한 최고의 방법이다. Facebook 과 Instagram 과 같은 큰 규모의 앱 제작에서도 사용되었다. React는 마치 프로그래머가 app 을 빌드하는 것처럼 app 에 대해 생각하게 만든다는 점이다.무슨말인지 이해가 가지 않을 것이다. 이번 문서에서는 React를 이용해서 검색을 할 수 있는 상품 테이블을 만드는 과정을 통해 위의 문장의 의미를 알아볼 것이다. - Start With A Mock 서버에 JSON AP.. 2021. 2. 11. 컴포넌트 결합 - SDP(안정된 의존성 원칙) - 이 글은 로버트 C.마틴의 Clean Architecture를 기반으로 작성되었습니다. (가능하면 책을 읽어보는것을 추천한다.) - 개요 더 안정된쪽으로 의존하라. 프로그램이 완성되거나 유지보수됨에 따라 설계는 계속 변한다. 초기에 변동성이 큰 컴포넌트를 만들었다고 가정하자. 추후 변경이 쉽지 않은 컴포넌트가 변동성이 큰 쪽에 의존한다면 어떨까? 변동성이 큰 컴포넌트를 변경하면 변경이 쉽지 않은 컴포넌트도 영향을 받으므로 변경이 어렵게 된다. SDP(안정된 의존성 원칙)를준수하면 변경하기 어려운 모듈이 변경이 쉬운 모듈에 의존하지 않도록 만들 수 있다. - 안정성 안정성이란 여러가지 의미가 될 수 있다. 책을 세웠다고 가정해보자. 이 책을 쓰러트리려면 대단한 수고를 들여야할까? 그렇지 않다. 손가락 .. 2021. 2. 10. 설계원칙 - SOLID(LSP) - 이 글은 로버트 C.마틴의 Clean Architecture를 기반으로 작성되었습니다. (가능하면 책을 읽어보는것을 추천한다.) - https://ko.wikipedia.org/wiki/%EC%A7%81%EC%82%AC%EA%B0%81%ED%98%95 - 개요 바바라 리스코프가 하위 타입에 대해 정의한 원칙이다. S 타입의 객체 o1, T 타입의 객체 o2가 있고, T 타입을 이용해서 정의한 프로그램 P에서 o2 대신 o1을 치환해도 P의 행위가 변하지 않는다면, S는 T의 하위타입이다. - LSP 예제 모델들을 관리하는 어플리케이션을 살펴보자. Model 클래스가 있다. 실세계에서는 상당히 많은 메소드가 있겠지만 이 예제에서는 모델 코드를 반환하는 getModelCode() 메소드만 있다고 가정한다.. 2021. 2. 10. 설계원칙 - SOLID(OCP) - 이 글은 로버트 C.마틴의 Clean Architecture를 기반으로 작성되었습니다. (가능하면 책을 읽어보는것을 추천한다.) - https://en.wikipedia.org/wiki/Open%E2%80%93closed_principle - 개요 소프트웨어 개체(클래스, 모듈, 함수)는 확장에는 열려있어야 하며, 변경에는 닫혀 있어야 한다. 즉, 개체의 행위는 확장할 수 있어야 하지만 이때 개체를 변경해서는 안된다. 만약 요구사항 확장하는데 기존 소프트웨어를 많이 수정해야 한다면 안된다는것이다. - 예제 특정 데이터를 가공하여 웹 페이지에 보여주는 시스템이 있다고 하자. 이때 갑자기 이해관계자가 PDF나 Excel 로 보여줄 수 있게 기능을 추가해달라고 한다. 이때 소스코드를 얼마나 변경해야 할까?.. 2021. 2. 10. 설계원칙 - SOLID(SRP) - 이 글은 로버트 C.마틴의 Clean Architecture를 기반으로 작성되었습니다. (가능하면 책을 읽어보는것을 추천한다.) - 개요 단일 책임 원칙은 가장 많은 오해를 사고 있는 원칙이다. 이름만 보면 마치 하나의 모듈은 하나의 일만 해야하는 것처럼 느껴진다. 하지만 이는 오해이다. 하나의 모듈은 하나의 액터(사용자 및 이해관계자)에 대해서만 책임져야 한다. 모듈이란 보통의 경우엔 소스파일이다. SRP를 위반하는 원칙들을 살펴보면서 SRP를 이해해보자. - 징후: 우발적 증복 급여 어플리케이션에서 Employee 클래스가 있고, 해당 클래스에서 calculatePay(), reportHours(), save() 메소드를 제공한다고 해보자. 이 클래스는 SRP를 위반한다고 할 수 있는데, diag.. 2021. 2. 10. UML - 클래스 다이어그램과 제약 규칙 - 이 글은 UML Distilled (마틴 파울러)책을 기반으로 작성하였습니다. - 제약 규칙 클래스 다이어그램을 작성할 때 시간이 많이 소요되는 부분은 무엇일까? 사각형을 그리고 화살표 방향을 정하는데 오래걸린다고 생각하겠지만 제약(constraint)을 표시하는데 많은 시간이 걸린다. 위 다이어그램에서 Order와 Customer의 다중성은 Order:Customer = *:1 이다. 만약 다중성이 헷갈린다면 한 요소를 1로 고정해놓고 생각해보길 바란다. 예를 들면 Order가 1개 라고 가정한다면 Customer는 1 명이다. 이번엔 반대로 Customer 가 1명이라면 이에 해당하는 Order는 다수이다. 또한 Order와 OrderLine, Product 관계에서 Line Item을 생각해보자.. 2021. 2. 10. 이전 1 다음
