추상과 구상 — 아키텍처의 심장부

웹·SQL

웹의 프론트·백엔드·DB 3계층과 GoF의 생성·구조·행위 3분류가 같은 구도를 공유하기 때문입니다 — 무언가를 만드는 계층, 형태를 갖추는 계층, 행동하는 계층이라는 감각이 양쪽에 겹쳐 있습니다.

웹·SQL

"질의(Query)는 상태를 바꾸지 않고, 명령(Command)은 결과를 반환하지 않는다"는 원칙으로 읽기와 쓰기의 책임을 갈라놓는 것입니다.

SELECT는 Query 쪽, INSERT·UPDATE·DELETE는 Command 쪽에 섭니다.

웹·SQL

목적별(DQL 조회 / DML 조작)과 대상별(DDL 구조 정의 / DCL 권한 / TCL 트랜잭션) 두 축입니다.

프로젝트 폴더 이름만 봐도 alembic/(구조=DDL)인지 apps/(데이터=DML)인지 짐작할 수 있습니다.

아키텍처

SRP(클래스는 하나의 책임만), OCP(확장에는 열려있고 수정에는 닫혀있게), LSP(자식이 부모 자리를 대체해도 안전하게), ISP(인터페이스를 필요한 만큼만 잘게), DIP(구체가 아니라 추상에 의존)입니다.

각각 클린 아키텍처의 특정 규칙으로 이어집니다.

아키텍처

Port는 추상(무엇을 할지만 정의한 인터페이스), Adapter는 구상(그것을 실제로 어떻게 구현할지)입니다.

제어의 흐름(요청이 들어오는 순서)과 의존성의 방향(누가 누구를 아는가)이 반대일 수 있다는 것이 이 구조의 핵심입니다.

스스로 확인

웹 3계층과 GoF 3분류가 같은 구도를 공유하기 때문입니다. 프론트는 사용자 행위에 반응(행위 패턴), 백엔드는 객체를 만들고 조합(생성 패턴), DB는 구조를 정의(구조 패턴)하는 역할을 맡습니다.

스스로 확인

"질의(Query)는 상태를 바꾸지 않고, 명령(Command)은 결과를 반환하지 않는다"입니다.

스스로 확인

읽기와 쓰기가 같은 모델을 써서 조회 성능 최적화가 어렵고, 복잡한 도메인 로직이 조회 기능 때문에 오염되기 쉽다는 것입니다.

스스로 확인

1단계는 클래스만(Command/Query 모델을) 분리하는 것이고, 2단계는 아예 읽기·쓰기 DB(저장소)까지 분리하는 것입니다.

스스로 확인

틀려도 되는 시간이 있느냐입니다. 잔액·재고처럼 즉시 정확해야 하는 곳에는 쓰면 안 됩니다.

스스로 확인

SELECT는 조회 전용(목적: 데이터 상태를 바꾸지 않음)이고, INSERT·UPDATE·DELETE는 데이터 상태를 실제로 변경하기 때문입니다.

스스로 확인

alembic/ 은 테이블 구조(스키마)를 정의·변경하는 폴더이고, apps/ 는 실제 데이터를 조회·조작하는 코드가 있는 폴더이기 때문입니다.

스스로 확인

그 모듈의 변경을 요청할 수 있는 이해관계자(주체)입니다. SRP는 정확히는 '변경 이유(액터)가 하나여야 한다'는 뜻입니다.

스스로 확인

DIP(Dependency Inversion, 의존성 역전)는 SOLID 원칙이고, DI(Dependency Injection, 의존성 주입)는 그 원칙을 실현하는 구현 기법입니다. DI를 써도 구상 클래스를 주입하면 DIP는 위반될 수 있습니다.

스스로 확인

모든 의존성은 안쪽 원(핵심 업무 규칙)을 향해야 한다는 것입니다.

스스로 확인

Entities(핵심 규칙) → Use Cases(애플리케이션 규칙) → Interface Adapters(통역 계층) → Frameworks & Drivers(가장 바깥, 세부 기술)입니다.

스스로 확인

Use Case는 '어떤 순서·규칙으로 할지'를 구체적으로 기술하는 비즈니스적 구상이기 때문입니다. 추상은 Port입니다.

스스로 확인

Outbound 구간입니다. 제어는 코어 → 어댑터로 흐르지만, 의존성(코드가 아는 방향)은 어댑터가 코어의 Port를 구현하는 방식이라 안쪽을 향합니다.

스스로 확인

ISP(인터페이스 분리 원칙)입니다. 쓰지 않는 메서드에 의존하지 않도록 인터페이스를 잘게 쪼갭니다.

자주 하는 실수

DIP는 Dependency Inversion(의존 역전)입니다. DI는 별개의 구현 기법입니다.

자주 하는 실수

구상 클래스를 주입하면 DI는 맞지만 DIP는 위반될 수 있습니다.

자주 하는 실수

비즈니스적 구상입니다. 추상은 Port입니다.

자주 하는 실수

코어가 선언합니다. 이 방향이 곧 DIP입니다.

자주 하는 실수

흐름과 의존성은 어긋납니다. Outbound 구간에서 화살표가 꺾입니다.

자주 하는 실수

성공/실패 또는 ID만 반환하는 것이 원칙입니다.

자주 하는 실수

1단계는 클래스만 분리합니다. 대부분은 여기서 끝내도 됩니다.

자주 하는 실수

잔액·재고엔 쓰면 안 됩니다. 틀려도 되는 시간이 있느냐가 기준입니다.

자주 하는 실수

TRUNCATE는 DDL이라 대체로 롤백이 불가능합니다. 되돌리려면 DELETE를 써야 합니다.

자주 하는 실수

정확히는 '변경 이유(액터)가 하나'여야 한다는 뜻입니다.

자주 하는 실수

반환값의 의미와 예외까지 같아야 지켜집니다.

용어

명령은 상태를 변경하는 작업(결과 데이터를 반환하지 않음), 질의는 상태를 변경하지 않는 조회(부작용 없음)입니다.

용어

DQL(SELECT, 조회), DML(INSERT·UPDATE·DELETE, 변경), DDL(CREATE·ALTER·DROP, 구조), DCL(GRANT·REVOKE, 권한), TCL(COMMIT·ROLLBACK, 트랜잭션)입니다.

용어

SRP(단일 책임), OCP(개방-폐쇄), LSP(리스코프 치환), ISP(인터페이스 분리), DIP(의존성 역전)입니다.

용어

클린 아키텍처에서 Controller·Presenter·Gateway로 이루어진 통역 계층입니다.

용어

Input Port는 외부가 코어를 호출할 때의 진입 계약, Output Port는 코어가 외부에 요청할 때의 출구 계약입니다.

용어

Inbound Adapter(Driving)는 외부 요청을 받아 Input Port를 호출(라우터·CLI), Outbound Adapter(Driven)는 Output Port를 구현(DB 리포지토리·파일 로더)합니다.

용어

기술적 구상은 어댑터(어떤 기술로 할지), 비즈니스적 구상은 유스케이스(어떤 순서·규칙으로 할지)입니다.

용어

제어의 흐름은 런타임(실행 시), 의존성의 방향은 컴파일타임(코드가 무엇을 import하는가)에 결정됩니다.

용어

목적별(DQL·DML)과 대상별(DDL·DCL·TCL) 두 축입니다.

용어

웹 3계층은 프론트·백엔드·DB이고, GoF 3분류는 생성·구조·행위입니다.

용어

SELECT는 질의(상태 안 바꿈) 쪽, INSERT·UPDATE·DELETE는 명령(상태 바꿈) 쪽입니다.

용어

DDL은 구조(틀을 만든다)를, DML·DQL은 데이터(틀 안을 채운다)를 조작합니다.

용어

확장에는 열려 있고 수정에는 닫혀 있어야 한다는 원칙입니다.

용어

안 쓰는 메서드에 의존하지 않도록 인터페이스를 쪼개는 원칙입니다.

용어

가장 안쪽 계층으로, 프레임워크와 무관한 핵심 업무 규칙입니다.

용어

가장 바깥 계층으로 교체 가능한 세부 기술을 담당합니다.

용어

실행 시 누가 누구를 호출하는가를 나타내는 런타임 개념입니다.