2nd/10_Wiki/Topics/Domain_Programming/Programming & Language/관심사의 분리 (Separation of Concerns).md

id, title, category, status, canonical_id, aliases, duplicate_of, source_trust_level, confidence_score, verification_status, tags, raw_sources, last_reinforced, github_commit, tech_stack

id	title	category	status	canonical_id	aliases	duplicate_of	source_trust_level	confidence_score	verification_status	tags	raw_sources	last_reinforced	github_commit	tech_stack
wiki-2026-0508-관심사의-분리-separation-of-concerns	관심사의 분리 (Separation of Concerns)	10_Wiki/Topics	verified	self	SoC Separation of Concerns 관심사 분리	none	A	0.9	applied	soc modularity design-principle architecture		2026-05-10	pending	language framework agnostic agnostic

관심사의 분리 (Separation of Concerns)

매 한 줄

"매 system 을 서로 겹치지 않는 concern 단위로 쪼개 각각이 독립 변경 가능하도록 한다". Dijkstra (1974) — 매 modularity 의 근본 원리. 매 layer / module / function / file 모든 scale 에 적용. 매 변경의 locality + 매 testability 를 동시에 얻는다.

매 핵심

매 SoC 의 본질

• Concern: 매 system 이 처리하는 distinct topic (UI, persistence, billing, auth).
• Separation: 매 concern 별로 코드/모듈/팀/배포 단위 분리.
• Independent change: concern A 의 변경이 B 의 코드 수정 X.

매 적용 scale

• Function: 매 single responsibility (SRP).
• Module: 매 cohesion 높음 + coupling 낮음.
• Layer: presentation / business / persistence (layered arch).
• Service: bounded context / microservice.
• Repository: monorepo path / multirepo.

매 응용

1. MVC / MVP / MVVM.
2. Clean / Hexagonal Architecture (port-adapter 분리).
3. Aspect-Oriented Programming (cross-cutting 분리).
4. Microservice (bounded context 분리).
5. CSS-in-JS vs separate stylesheet — 매 variant.

💻 패턴

Function-level: 매 1 함수 = 1 개념

// ❌ Mixed
function processOrder(input: any) {
  if (!input.email) throw new Error("invalid");          // validation
  const tax = input.amount * 0.1;                        // tax calc
  db.execute("INSERT INTO orders ...");                  // persistence
  smtp.send(input.email, "Confirmed");                   // notification
}

// ✅ Separated
function validate(input: OrderInput): Order { /* ... */ return order; }
function computeTax(order: Order): Money { /* ... */ }
async function persist(order: Order, tax: Money): Promise<OrderId> { /* ... */ }
async function notify(order: Order): Promise<void> { /* ... */ }
async function processOrder(input: OrderInput) {
  const order = validate(input);
  const tax = computeTax(order);
  const id = await persist(order, tax);
  await notify(order);
  return id;
}

Module: 매 dependency direction

src/
├── domain/        ← 매 pure logic (no IO)
├── application/   ← 매 use cases (orchestration)
├── infrastructure/ ← DB, HTTP, queue
└── interface/     ← controller, CLI

MVC (web)

# model.py
class User: ...

# view.py (template)
def render_user(user): ...

# controller.py
def get_user(req):
    user = User.find(req.params["id"])
    return render_user(user)

CSS 분리 (concern: layout / theme / interaction)

/* layout.css */
.container { display: grid; grid-template-columns: 240px 1fr; }
/* theme.css */
:root { --bg: #fff; --fg: #111; }
.dark { --bg: #111; --fg: #eee; }
/* interaction.css */
.btn:hover { transform: translateY(-1px); }

Hexagonal port-adapter

// domain port (concern: business)
export interface OrderRepo {
  save(o: Order): Promise<void>;
  findById(id: OrderId): Promise<Order | null>;
}

// adapter (concern: infra)
export class PostgresOrderRepo implements OrderRepo { /* SQL */ }
export class InMemoryOrderRepo implements OrderRepo { /* test */ }

AOP (cross-cutting) — Spring

@Aspect @Component
class TxAspect {
  @Around("@annotation(Transactional)")
  Object inTx(ProceedingJoinPoint pjp) throws Throwable {
    var tx = txManager.begin();
    try { var r = pjp.proceed(); tx.commit(); return r; }
    catch (Throwable t) { tx.rollback(); throw t; }
  }
}
// 매 business code 에서 tx 코드 누설 X

Bounded context (microservice 단위)

billing-service/   ← 매 invoice, charge
inventory-service/ ← 매 stock
shipping-service/  ← 매 carrier integration
# 매 각자 DB, 각자 deploy, 각자 schema

매 결정 기준

상황	Approach
매 small script	function-level SRP 만
매 medium app	layered + module 단위
매 complex domain	hexagonal + bounded context
매 large org	microservice + team boundary
매 cross-cutting (log, tx, auth)	AOP / middleware / interceptor

기본값: 매 layered + DI + interface boundary. 매 over-fragmentation (매 1 함수 1 파일) 의 X.

🔗 Graph

• 부모: Software Design Principles
• 변형: Single Responsibility Principle (SRP) · Modularity
• 응용: Layered Architecture · Hexagonal Architecture · Microservices
• Adjacent: SOLID · Aspect-Oriented Programming (AOP)

🤖 LLM 활용

언제: refactor proposal, code smell detection (mixed concerns), boundary 설정. 언제 X: 매 throwaway script — overhead 만.

❌ 안티패턴

• God Module / God File: 매 모든 concern 의 mix.
• Shotgun Surgery: 매 1 변경이 매 N 파일 수정 — 매 concern 의 분산 잘못.
• Premature decomposition: 매 unclear boundary 의 microservice 분할 — 매 distributed monolith.
• Leaky abstraction: 매 infra 의 domain 누수 (e.g. ORM annotation 의 domain entity 노출).

🧪 검증 / 중복

• Verified (Dijkstra "On the role of scientific thought" 1974, Parnas "On the Criteria To Be Used in Decomposing Systems into Modules" 1972).
• 신뢰도 A.

🕓 Changelog

날짜	변경
2026-05-08	Phase 1
2026-05-10	Manual cleanup — SoC 본질 + scale + MVC + hexagonal + AOP