아키텍처 | chankoo

Restful API

2024-04-21 · api drf

REST(REpresentational State Transfer) 의 설계 원칙을 잘 지킨 API로, URI로 리소스를, HTTP METHOD로 행위를 표현하는 아키텍처이다. Restful API는 아래 특성을 만족한다. Uniform Interface를 제외하고는 http 와 큰 차이가 없다. Uniform Interface Stateless Cacheable Client - Server Layered System Uniform Interface은 아래와 같은 조건을 일관되게 만족하는 것을 의미한다. Identification of resources(by …

모바일 앱 개발 옵션

2024-04-07 · #frontend 모바일 iOS android

모바일 앱 개발이 필요하다면, 선택지는 보통 아래와 같다. 네이티브 특정 OS 전용으로 개발하는 앱이다. iOS 앱을 Swift로, 안드로이드 앱을 Kotlin으로 개발하는 것 기기의 리소스(카메라, 알림, 네이티브 api 등)와 데이터(주소록, 파일 등)를 제약없이 사용할 수 있고, 성능이 가장 좋다 OS마다 별도로 개발해야해서 비용이 가장 크다 크로스 플랫폼 OS와 무관하게 하나의 언어로 개발할 수 있는 기술 React Native라면 JS로, Flutter라면 Dart로 개발하고, 빌드 타임에 각 OS에 맞게 언어를 변환한다. 기기의 리소스를 활용하면서도 개발 …

Domain Driven Design

2023-12-20 · 책 DDD

Domain과 Model Domain은 사용자가 SW를 사용하는 대상 영역을 말한다 SW의 본질은 (해당 도메인에서)사용자의 문제를 해결하는 것이다 그러므로 개발은 사용자 활동에 관련한 지식 체계에 집중해야 한다 지식의 양이 방대하므로 Model을 통해 추상화한다 Model의 유용성 모델과 핵심 설계는 서로 영향을 주며 구체화된다 유지보수와 계속되는 기능 개선을 가능케 한다 모델은 모든 구성원이 사용하는 언어의 중추이다 개발자와 도메인 전문가의 의사소통시 번역이 불필요하다 언어가 모델이 긴밀히 연결되므로 언어를 통해 모델을 정제할 수 있다 모델은 지식의 정수만을 뽑아 …

객체지향의 사실과 오해

2023-12-20 · 책 OOP

오해를 덜어낸 객체지향 구현 로직 (클래스가 아니라)특정한 객체를 상상하고, 우선 객체의 행동을 정의하자 정의된 행동을 기반으로 협력의 공동체를 상상해보자. 이 공동체는 요청과 응답의 흐름으로 소통할 것이고 공동체의 구성원에게는 여러가지 책임이 할당된다 다음으로 협력에 필요한 데이터 필드가 있다면 이를 정의하자. 잊지말자 상태보다 협력이 우선이다 마지막으로, (이제서야) 클래스를 구현해야한다. 게다가 클래스는 ‘타입’을 구현하기 위한 수단에 불과하다 더 구체적인 설계와 구현 구조설계: …

캡슐화

2023-12-20 · OOP

OOP에서 1) 객체의 attribute와 method를 하나로 묶고 2) 실제 구현 내용을 내부에 감추는 일. 캡슐화는 객체간 종속을 인터페이스 레벨에 묶어두어 모듈의 결합도를 낮춘다. refs 캡슐화 - 위키백과, 우리 모두의 백과사전 객체지향의 사실과 오해 links

컴포넌트 설계 원칙

2023-12-20 · 컴포넌트

content 응집도 높은 컴포넌트를 설계하려면, 1) REP 2) CCP 3) CRP 원칙을 기억해야한다. 세 원칙은 상충하기에 설계 목적에 따라 세 원칙간 균형을 잡아야한다. 컴포넌트의 결합을 잘 설계하려면, 1) ADP 2) SDP 3) SAP 를 이해해야한다. ADP(Acyclic Dependencies Principle)은 컴포넌트 간 의존성이 순환하지 않도록 하여 컴포넌트 간 의존을 끊는 최소한의 규칙이고, SDP(Stable Dependencies Principle)은 안정된(변화가 적은) 모듈이 불안정한(변화가 많은) 모듈에 의존하지 않도록 설계하는 규 …

추상 팩토리 패턴

2023-12-02 · 디자인패턴

객체 생성을 위해 구체 팩토리에 의존(요소 -> 팩토리)하는 것이 아니라, 추상 팩토리에 의존(요소 -> 추상 팩토리 $\Leftarrow$ 구체 팩토리)하는 패턴이다. DIP의 전형적인 예시이다. refs links DIP

CAP

2023-12-02 · 분산시스템

CAP Theorem. 분산 시스템에서 CAP의 세가지 조건이 동시에 만족할 수 없다는 정리이다. Consistency(일관성): 일관된 읽기를 보장 Availability(가용성): 응답을 보장 Partition tolererance(분할 용인): (네트워크 실패를 가정) 일부 메시지가 드랍되어도 시스템이 동작함 P의 조건은 분산 시스템과 네트워크의 본질이므로, 시스템 구현시 CP 또는 AP를 선택하는 문제만 남는다. refs CAP Theorem, 오해와 진실 links

비동기

2023-11-22 · 동시성

동기적이지 않은 것(asynchronous)을 의미한다. 동기적이라는 건 작업들을 순차적으로 진행함을 의미하는데, 한 작업이 끝나기를 기다려야하는 속성이 있다. 반면에 비동기는 한 작업이 끝나기를 기다리지 않고 다른 작업을 진행하는 것을 말하며, 동기적이지 않은 모든 방식을 의미한다. 비동기 프로그래밍을 가능케하는 조건 non-block IO - 요청을 block하는 작업이 아니기에 I/O를 기다리는 동안 다른 작업을 처리(async, non-block)할 수 있다. 멀티 스레딩 - 여러 작업을 각 스레드가 나누어 진행하기에 동기적이지 않다. block IO 작업이라 …

적당히 타협한 Django 아키텍처

2023-11-09 · django MSA DDD

Django는 아래와 같은 특성 때문에 클린 아키텍처와 DDD를 적용하기 어렵다. (프레임워크의 의도와 다르게 코드를 작성해야하는 경우가 생긴다.) 액티브 레코드 패턴을 사용하는 Model -> 도메인 모델로만 사용하기 어렵고 DB 테이블 구조와 밀접하게 연관 비즈니스 로직과 엮여있는 View -> 뷰에 비즈니스 로직을 구현하기 쉬운 구조 Django ORM -> 데이터를 가져오고 저장하는 방식이 특정 ORM 코드에 종속됨 차선으로 DDD를 선택적으로 적용한 Layered 아키텍처를 생각한다. MSA로 확장 가능성을 고려해서, …

구글 엔지니어는 이렇게 일한다

2023-11-08 · 책

소프트웨어 엔지니어링의 특징(프로그래밍과 비교한) sustainability 시간이 흐름에 따라 요구되는 기술적, 비즈니스적 변화에 capable 해야함 코드의 지속가능성을 높이는 방향성 기발한(clever) 코드가 아니라 클린한 코드 변할 가능성이 있는 의존을 제거함 규모 확장성 (주로)조직 규모, (부가적으로) 컴퓨트 자원 확장에 드는 비용보다 효용이 높은 상태를 유지해야함 트레이드 오프 만병통치약은 없으며 모든 선택 간 트레이드 오프를 따져야함 가설과 추정으로 선택하는 것도 좋지만 데이터로 근거있는 결정을 내리는게 중요할 때가 있다 refs links

마이크로서비스 패턴 모음

2023-06-07 · MSA 분산시스템 DDD

패턴 개괄 애플리케이션 패턴(application pattern): 개발자가 맞닥뜨리는 문제를 해결합니다. 분해: 시스템을 여러 서비스로 분해하는 기준을 결정하는 것. 비즈니스 능력 <-> 하위 도메인(DDD) 쿼리: 분산 db에서 쿼리하는 방법 API 조합 <-> CQRS 데이터 일관성: 분산 db 간 일관성 유지하는 방법 참고 - 2PC는 가용성 이슈와 성능 이슈 때문에 제외 테스트 자동화: 가급적 E2E를 피하고, 서비스 별로 분리하여 테스트하는 단순화가 필요 consumer-driven contract test / consumer-side …

API 조합 패턴

2023-06-01 · MSA api

(주로)MSA에서 프로바이더 서비스들이 제공하는 데이터를 조합하여 한번에 제공하는 API 조합기를 두는 패턴 설계 API 조합기로 둘 컴포넌트 선정 클라이언트 간단하지만, 클라이언트가 외부 네트워크에 존재하는 경우 느리다 API 게이트웨이 일반적인 방법으로 API 게이트웨이 패턴이라 불림 스탠드 얼론 서비스 ‘주문 검색 서비스’ 와 같은 서비스를 두어 조합기 역할을 맡기는 방법 효율적인 조합 로직 프로바이더 서비스 순차 호출에 따른 지연 시간을 줄이는 것이 핵심 리액티브 프로그래밍을 권장 refs 마이크로서비스 패턴 links API …

서비스 메시

2023-05-24 · MSA

content 프록시를 사용하여 서비스 간의 통신을 관리하는 인프라 계층. 도커와 쿠버네티스는 수많은 마이크로서비스의 오케스트레이션을 가능하게 하였고, 이들 서비스 간에 흐르는 트래픽을 추적하고 관리하려는 목적으로 서비스 메시를 사용한다. (어플리케이션 레벨이 아니라) 인프라 레벨에서 1) 트래픽 관리 2) observability 3) 보안 강화의 기능을 제공한다. refs 실무자를 위한 서비스 메시 - 지금 서비스 메시가 의미 있는 이유 links

API Gateway 패턴

2023-05-18 · MSA api

API Gateway Pattern 을 정확히 이해하자 MSA에 API Gateway Pattern이 필수적임 API Gateway Pattern은 API Gateway Framework와는 무관함 내부 api를 제공(단순 라우팅)할 용도로 API Gateway Framework를 쓰지말자 -> controller와 facade가 없는 프레젠테이션 레이어를 구현하게됨 인가 로직이 비즈니스 레이어(각각의 마이크로서비스)에 들어가야해서 오염됨 로직 구현의 책임을 잘못된 곳에 전가함 클라이언트가 여러 로직을 직접 호출하여 조합하거나 특정 서비스가 자신의 도메인인 것처 …

CQRS

2022-12-12 · MSA

Command와 Query를 다른 것으로 보고 명시적으로 분리하는 패턴. OOP 관점에서 Command를 담당하는 객체와, Query를 담당하는 객체의 책임을 분리하는 것으로 이해하면된다. MSA, DDD, 이벤트 소싱 등 다른 기술과 함께 활용되며 다양하게 구현한다. 특히 마이크로 서비스로 분리한 아키텍처에서는 Query가 어려운데, 여러 서비스에 흩어진 데이터를 조회하는 비용이 크기 때문이다. 그래서 Query 효율을 높이는 관점에서 CQRS를 많이 활용한다. refs 마이크로서비스 패턴 links

트랜잭션 스크립트

2022-12-11 · MSA

동작을 구현한 클래스와 상태를 표현하는 클래스를 분리하여, 비즈니스 로직을 요청 타입에 따라 별도로 구분된 절차적 트랜잭션 스크립트로 작성한 패턴이다. 구현이 쉽고 빠르며, 비교적 단순한 비즈니스 로직에 적합하다. 동작과 상태를 모두 구현하여 책임을 분리한 도메인 모델과는 대비되는 개념이다. 비즈니스 로직이 복잡해지고 여러 클래스가 복잡하게 얽힐수록, OOP적으로 잘 설계된 도메인 모델의 가치는 높아진다. 도메인 모델 패턴에서는 도메인 객체가 비즈니스 로직을 처리하여, 서비스 클래스는 가벼워진다. refs 마이크로서비스 패턴 Django와 Layered …

좋은 코드 나쁜 코드

2022-12-09 · 책

refs links

2PC

2022-12-06 · MSA 분산시스템

2단계 커밋(Two Phase Commit) 으로 분산 트랜잭션 환경에서 트랜잭션을 구현하는 방법이다. 트랜잭션의 커밋을 준비와 실제 동작의 2단계로 나누어, 분산 환경에서 커밋 준비가 완료되면 비로소 실제 커밋을 하는 방식이다. 2PC 에서 원자성은 2개의 되돌릴 수 없는 포인트에 의해 결정되는데, 1) 참여자가 준비 단계에서 커밋 가능하다고 답변하는 시점과 2) 코디네이터(리소스 매니저)가 커밋하는 시점이다. 1)과 2) 가 만족되면 참여자의 커밋이 어떤 사유로 실패하든, 반복적으로 커밋을 시도한다. 트랜잭션에 관여하는 모든 서비스가 정상 동작해야하는 가용성 이슈 …

Saga 패턴

2022-12-06 · MSA 분산시스템

content 분산 트랜잭션 환경에서 서비스 간 비동기 메시징을 이용하여 편성한 일련의 로컬 트랜잭션. 각 서비스가 변경분 커밋을 수행하고 완료 메시지를 발행하여 다음 서비스의 트랜잭션을 유도한다. 마찬가지로 각 서비스는 보상 트랜잭션(compensatable transaction)을 통해 문제 발생 시 변경분을 발생 역순으로 undo하도록해 롤백한다. 분상 환경에서 메시징을 이용하는 특성상, saga 그 자체로는 엄격한 Isolation을 제공할 수 없다. 메시지 읽고 처리하는 행위를 격리하기 힘들기에, 메시지 읽는 순서가 바뀐다든지 하는 이슈로 트랜잭션의 결과가 …

분산 트랜잭션

2022-12-06 · MSA 분산시스템

content 트랜잭션의 속성(ACID)을 2개 이상으로 분산된 네트워크에서도 만족시키는 트랜잭션. X/Open DTP(XA) 모델이라는 표준이 있으며, 이는 2단계 커밋(2PC)를 활용하여 각 리소스를 트랜잭션으로 관리한다. 요즘엔 2PC 대신 Saga 패턴을 쓰는 추세이다. refs 분산 트랜잭션 - 위키백과, 우리 모두의 백과사전 X/Open XA - 위키백과, 우리 모두의 백과사전 마이크로서비스 패턴 links Transaction 2PC Saga 패턴

마이크로서비스 패턴

2022-11-27 · 책 MSA 분산시스템

refs links

험블 객체 패턴

2022-11-03 · 디자인패턴

content 테스트를 더 잘하기 위한 패턴으로, 테스트하기 어려운 행위는 ‘험블 객체’로 추출해 객체의 역할을 최소화 시키는 방식이다. 흔한 예로, 험블 객체 패턴으로 프레젠터와 뷰를 나누게 되는데, UI 와 엮인 행위는 테스트가 어려우므로 뷰에 UI 관련 행위만 남겨놓는 것이다. 데이터를 처리하는 행위는 프레젠터가 책임지고 테스트를 완수하며, 뷰는 데이터를 넘겨 받아 뿌려주는 역할만 하는 보잘 것 없는(humble) 모듈이 된다. refs 클린 아키텍처 links

CRP

2022-10-31 · 컴포넌트

content 공통 재사용 원칙; Common Reuse Principle 컴포넌트의 요소가 공통적으로 재사용하는 모듈만 컴포넌트에 포함하라. 컴포넌트 속 모듈(A)은 사실상 해당 컴포넌트의 모든 모듈과 의존성을 지닌다고 할 수 있다. 다른 모듈이 A에 직접 의존하지 않는다고해도, A의 변경으로 다른 모듈에 변화(재컴파일, 재검증, 재배포)가 발생할 가능성이 있어서 그렇다. 그래서 CRP는 컴포넌트 내 모듈과 강하게 결합하지 않는 모듈(A)을 컴포넌트에 위치시키지 말라고 조언하는 배제의 원칙으로서 기능한다. refs 클린 아키텍처 links 컴포넌트

CCP

2022-10-31 · 컴포넌트

content 공통 폐쇄 원칙; Common Closure Principle 컴포넌트는 변경에 대해 닫혀있는 수준이 공통적이어야한다. 즉, 컴포넌트 변경하는 이벤트는 동일한 시점에 동일한 사유로 발생해야하며, 그 외 이벤트로는 변경이 불가해야한다. 하나의 모듈이 하나의 액터만 책임진다는 SRP의 컴포넌트 수준 원칙이다. 변경 사유가 다른 모듈은 별개 컴포넌트로 분리해야한다, OCP 의 Closure와 동일한 의미의 닫혀있음이다. refs 클린 아키텍처 links 컴포넌트 SRP OCP

REP

2022-10-31 · 컴포넌트

content 재사용/ 릴리즈 등가 원칙; Reuse/ Release Equivalence Principle 재사용 단위는 릴리즈 단위와 같아야한다. 즉, 릴리즈 단위인 컴포넌트는 같은 목적으로 재사용 하는 모듈들로 구성해야한다. refs 클린 아키텍처 links 컴포넌트

ISP

2022-10-30 · SOLID

인터페이스 분리 원칙; Interface Separation Principle 인터페이스를 분리하여, 요소가 사용하는 인터페이스에만 의존하도록 설계해야한다. refs 클린 아키텍처 links SOLID

다형성

2022-10-30 · OOP

한 객체가 여러 형(type)에 속할 수 있는 프로그래밍 언어의 속성. 객체 지향 언어는 동적 바인딩을 제공하여 런타임에 객체의 형을 확정할 수 있게 한다. 다형성은 객체의 구현 타입에 의존하지 않고 (인터페이스에 의존하는) 추상적인 설계를 가능하게해 요소 간 결합도를 낮춘다. refs 다형성 (컴퓨터 과학) - 위키백과, 우리 모두의 백과사전 links

LSP

2022-10-30 · SOLID

리스코프 치환 원칙; Liskov Subsitution Principle 상위 타입 객체는 하위 타입 객체로 별도 조작 없이 치환 가능해야한다. 객체 지향 언어는 다형성을 제공하기에, LSP를 지킨 설계를 활용하기 유리하다. 사용할 하위 타입을 런타임에 선택하여 상위 타입을 대체하기 용이하다. LSP를 위반하면 OCP를 위반하는 것이다. 하위 타입을 추가(확장)하여 상위 타입을 바로 대체할 수 없기 때문이다. LSP를 위반한다면 보통 해당 객체를 사용하는 클라이언트 코드를 수정해야한다. 그리고 이 수정은 끔찍한 형태로 의존을 낳는다. 흔히 드는 예시가 직사각형을 상속 …

OCP

2022-10-28 · SOLID

개방-폐쇄 원칙; Open Close Principle 소프트웨어 요소는 확장에는 open, 수정에는 close여야 한다. 수정 보다 비용이 적은 확장으로 소프트웨어를 수정해야한다. OCP를 지키기 위해서는 의존 관계를 잘 설계해야한다. 의존 관계가 확장 가능한 요소와 수정해야하는 요소를 결정짓기 때문인데, A -> B (A가 B에 의존)이라면 A는 확장 가능한 요소이고 B는 수정해야하는 요소가 되는 것이다. 이를 위해 DIP를 지켜야한다. 추상 보다 구현의 변화가 많은데, 구현이 추상에 의존해야 구현을 확장할 수 있기 때문이다. 모듈 레벨(OOP 클래스)에만 …

컴포넌트

2022-10-27 · 컴포넌트

런타임에 소프트웨어를 구성하는 요소. (컴파일 언어의 경우) 실행 가능한 바이너리 형태이며, 코드로 확인 가능한 모듈과 달리 가시성이 없다. (잘 설계한다면)컴포넌트는 독립적으로 배포 가능한 단위이다. 시스템은 컴포넌트 단위로 쪼개지며, 각 컴포넌트는 다른 컴포넌트에 영향 주지 않고 개발, 배포한다. refs 개발자에서 아키텍트로 클린 아키텍처 links 모듈 컴포넌트 설계 원칙

모듈

2022-10-27

설계 시점에 다루는 코드 덩어리. 시점상 가장 먼저 구현하는 단위 refs 개발자에서 아키텍트로 클린 아키텍처 links 컴포넌트

개발자에서 아키텍트로

2022-10-27 · 책

아키텍트는 기술과 비즈니스 그리고 사용자를 모두 이해해야한다. 유저영역의 문제를 엔지니어링 관점에서 정의하여 소프트웨어 아키텍처를 설계한다. 아키텍처는 품질 속성과 기술 부채를 고려하여 시스템을 요소로 분리해야한다. 그리고 큰 그림 속에서 요소들을 연결하고 통합한다. 아키텍트로서 프로젝트 정리 이해관계자들은 누구였고 주요 비즈니스 목표는 무엇이었는가 최종적으로 어떤 결과를 도출했는가 어떤 기술을 사용했는가 가장 큰 리스크는 무엇이었고, 어떻게 극복했는가 다시 시작할 수 있다면 어떤 점을 다르게 하겠는가 refs links

SOLID

2022-10-27 · SOLID

모듈 수준의 소프트웨어 설계 원칙으로 다섯가지 원칙의 앞글자를 따서 부른다. refs 클린 아키텍처 links 모듈 SRP OCP LSP ISP DIP

SRP

2022-10-27 · SOLID

단일 책임 원칙 - Single Responsibility Principle 모듈은 한 액터(사용자, 이해관계자)만 책임진다. 모듈을 변경한다면 그 이유는 반드시 한 액터 때문이어야 한다. SRP를 따르면, 여러 액터의 요구를 책임지는 모듈은 책임을 찢어야 한다. 예를 들어 클래스 Employee가 재무팀을 위한 급여 계산 / 인사팀을 위한 업무 시간 계산을 책임지고 있다면, 이는 SRP를 위반한다. 그래서 -> 급여 계산을 위한 클래스와 업무 시간 계산을 위한 클래스로 책임을 분리하고, EmployeeFacade 클래스를 두어 인터페이스를 정리할 수 있다.

GoF의 디자인 패턴

2022-10-27 · 책 디자인패턴

refs links

퍼사드 패턴

2022-10-27 · 디자인패턴

content 서브 시스템(클래스들)을 숨기고 대표 인터페이스 하나(퍼사드)만 공개하는 디자인패턴. 퍼사드는 서브시스템 내 모든 인터페이스 집합을 상위 수준에서 제공한다. 객체 캡슐화와 유사한데, 캡슐화는 객체의 구현을 감추는 것이고 퍼사드는 서브 시스템의 구현을 감춘다. refs GoF의 디자인 패턴 links 캡슐화

설계 최적점

2022-10-13

프로젝트 규모에 따라 설계 최적점이 다르다. 일반적으로 큰 규모 프로젝트 일수록, 설계 시간을 투입함에 따라 재작업 비용을 크게 줄일 수 있기 때문이다. refs 개발자에서 아키텍트로 links

소프트웨어 아키텍트

2022-10-10

content 상위 수준의 설계 결정을 내리는 소프트웨어 전문가 좋은 아키텍트는 항상 ‘선택사항을 열어두는’ 방향으로 결정한다. 향후 시스템 변경이 필요할 때 핵심이 아닌 세부 사항은 언제든 바꿀 수 있어야 하는 것이다. Software Design 과는 구분해야하는데, Software Design은 코드 레벨 디자인을 담당한다. ex) 클래스 디자인, 모듈 정의, 함수 기능 정의 아키텍트는 코딩 줄여야한다 vs 코딩 못하면 뜬구름 잡는다 “소프트웨어 아키텍트라면 코드 수준을 벗어나 고수준 문제 해결에 집중해야한다는 거짓말에 속아선 안 …

DIP

2022-10-06 · SOLID

Dependency Inversion Principle(의존성 역전 원칙) 더 구체적인(하위 계층) 모듈에 의존하는 일반적(절차적)인 의존성의 흐름을 역전 시켜 더 추상적인(상위 계층) 모듈에 의존하도록해야한다. ex) 클라이언트 클래스에서 추상 팩토리와 연관 맺고, 런타임에 구체 팩토리를 의존성 주입하는 추상 팩토리 패턴. 클라이언트 클래스가 하위 계층에 의존하지 않고 상위 계층에 의존하는 것임 refs 클린 아키텍처 links SOLID

DI

2022-10-06 · 디자인패턴

Dependency Injection(의존성 주입) 클라이언트에서 사용할 의존성을 외부에서 넣어주는 일 refs links

IOC

2022-10-06 · 디자인패턴 spring

Inversion Of Control(제어 역전) 클라이언트(프로그래머)가 직접 사용할 의존성을 제어하는 상황(일반적, 절차적) -> 누군가(프레임워크)가 의존성을 정해주는(DI, DIP 등으로) 상황(역전) refs 학습 페이지 [Study]IoC, DI, DIP 개념 잡기 - 기록은 기억을 지배한다 links DI DIP

클린 아키텍처

2022-10-04 · 책 컴포넌트

refs links

프로그래밍 패러다임

2022-10-04 · OOP 함수형프로그래밍

content 클린 아키텍처 에 따르면, 프로그래밍 패러다임은 아래 세가지 뿐이다. 패러다임은 패러다임에 맞게 구현된 도구를 사용하거나, 그렇지 않은 도구를 사용하지 않음으로써, 프로그래머의 권한을 제한한다. 구조적 프로그래밍(structured programming) 프로그래머가 직접적으로 흐름을 통제하는 일을 제한한다. goto 문을 없애는 것 객체 지향 프로그래밍(OOP, object oriented programming) 프로그래머가 간접적으로 흐름을 통제하는 일을 제한한다. 함수 포인터를 사용해 런타임에 실행 함수를 결정하는 일 -> 다형성 문법을 따르 …

MVVM

2022-10-03 · 디자인패턴 frontend iOS

content View -> ViewModel -> Model 의 구조. View 를 그리기 위한 데이터와 비즈니스 로직을 ViewModel에 모두 담아 View와 Model 결합을 끊는다. MVC(UIKit) 를 이용하던 iOS 개발의 대세 흐름이 MVVM(SwiftUI)을 이용하는 것으로 변했는데, MVC에 비해 각 계층이 더 잘 분리되어 유지보수와 테스트가 더 용이하다. MVVM은 View가 ViewModel을, ViewModel이 Model을 소유하는 방식인데, MVC의 ViewController가 Model과 View를 모두 떠맡아 비대해지는 이슈 …

Container-Presenter 패턴

2022-10-03 · 디자인패턴 react

content 리액트에서 로직과 뷰 컴포넌트를 분리하는 패턴. 데이터를 가져오고 가공하는 컨테이너 컴포넌트와, 데이터를 렌더링하는 프레젠터 컴포넌트로 나눈다. aka Smart & Dumb conponents 대개 컨테이너는 렌더링하는 컴포넌트 외에 다른 ui는 렌더링하지 않으며, 프레젠터는 컨테이너로 부터 데이터를 받아 단순히 렌더링 한다. 관심사 분리를 통해 재사용성 높은 순수한 프레젠터 컴포넌트를 만드는 이점이 있으며, 테스트가 쉬워서 험블 객체 패턴을 따랐다고도 볼 수 있겠다. 반면 데이터 가져오는 역할을 hook이 점차 대체하며, 굳이 컨테이너 컴포넌 …