2nd/10_Wiki/Topics/AI_and_ML/Architecture_Styles.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-architecture-styles	Software Architecture Styles	10_Wiki/Topics	verified	self	아키텍처 스타일 architecture styles system architecture design patterns	none	A	0.92	applied	architecture system-design layered clean-architecture ddd microservices eda hexagonal		2026-05-10	pending	language framework language-agnostic any

Software Architecture Styles

📌 한 줄 통찰

시스템 의 component 의 구성 + interaction 의 fundamental pattern. 매 codebase 의 first read 의 shortcut. 매 wrong style = 매 매 fight 매 month. 선택 기준 = team + scale + change frequency.

📖 핵심

매 5 가지 major style

1. Layered (계층형)

• 매 horizontal layer: Presentation → Business → Data.
• 매 strict downward dependency.
• ✅ 매 simple. ✅ 매 entry-level.
• ❌ 매 cross-cutting concern (logging, auth) 의 awkward.
• ❌ 매 layer 의 leak 의 architecture 의 부패.

2. Clean Architecture (Uncle Bob)

• 매 entity / use case 의 center.
• 매 framework / DB 의 outer layer (adapter).
• 매 dependency 의 inward.
• ✅ 매 testable, framework-independent.
• ❌ 매 boilerplate (port + adapter).

3. Hexagonal (Ports & Adapters)

• 매 Clean 의 변형.
• 매 input port (use case) + output port (repository).
• ✅ 매 testable. ✅ 매 swap-able tech.

4. DDD (Domain-Driven Design)

• 매 module 의 Bounded Context.
• 매 ubiquitous language.
• 매 Entity / Value Object / Aggregate.
• ✅ 매 complex business.
• ❌ 매 simple CRUD 의 over-engineering.

5. Microservices

• 매 small + independent service.
• 매 single business capability.
• ✅ 매 scale + team autonomy.
• ❌ 매 distributed complexity (network, data consistency, observability).

6. Event-Driven (EDA)

• 매 message broker (Kafka, RabbitMQ).
• 매 producer + consumer 의 async.
• ✅ 매 decoupling. ✅ 매 scale.
• ❌ 매 ordering / debugging 어려움.

7. Serverless

• 매 FaaS (Lambda).
• 매 stateless function.
• ✅ 매 cost (idle 0).
• ❌ 매 cold start. 매 vendor lock-in.

매 trade-off matrix

Style	Complexity	Scale	Team	Cost
Monolith	Low	Low-Mid	Small	Low
Layered	Low	Mid	Small-Mid	Low
Clean	Mid	Mid	Mid	Mid
DDD	High	Mid-High	Mid-Large	High
Microservices	High	High	Large	High
EDA	High	Very High	Mid-Large	Mid
Serverless	Mid	Auto	Small-Mid	Variable

매 architecture drift

• 매 time 의 codebase 가 design 에서 멀어짐.
• 매 layer violation 의 build-time check (tsc-strict, archunit, dependency-cruiser).
• 매 ADR (Architecture Decision Record) 의 history.

매 anti-corruption layer (ACL)

• 매 external system 의 model 의 leak 방지.
• 매 boundary 의 translation.

💻 패턴

Clean Architecture (TS)

// domain/entities/User.ts (no framework)
export class User {
  constructor(public id: string, public email: string) {}
  changeEmail(newEmail: string) { 
    if (!isValidEmail(newEmail)) throw new InvalidEmail();
    this.email = newEmail;
  }
}

// application/usecases/UpdateUser.ts
export class UpdateUserUseCase {
  constructor(private userRepo: UserRepository) {}
  async execute(id: string, email: string) {
    const user = await this.userRepo.findById(id);
    user.changeEmail(email);
    await this.userRepo.save(user);
  }
}

// application/ports/UserRepository.ts (interface)
export interface UserRepository {
  findById(id: string): Promise<User>;
  save(user: User): Promise<void>;
}

// infrastructure/PrismaUserRepository.ts (adapter)
export class PrismaUserRepository implements UserRepository {
  async findById(id: string) { /* prisma ... */ }
  async save(user: User) { /* prisma ... */ }
}

→ 매 dependency 가 inward. 매 domain 가 prisma 의 모름.

Hexagonal port

// 매 input port
interface CreateOrder { execute(cmd: CreateOrderCommand): Promise<OrderId>; }

// 매 output port
interface OrderRepository { save(o: Order): Promise<void>; }
interface PaymentGateway { charge(amount: Money): Promise<TxId>; }

class CreateOrderHandler implements CreateOrder {
  constructor(private repo: OrderRepository, private payment: PaymentGateway) {}
  async execute(cmd: CreateOrderCommand) {
    const order = Order.create(cmd);
    const tx = await this.payment.charge(order.total);
    order.confirmPayment(tx);
    await this.repo.save(order);
    return order.id;
  }
}

EDA (Kafka)

// Producer
await producer.send({
  topic: 'order.created',
  messages: [{ key: order.id, value: JSON.stringify(order) }],
});

// Consumer
await consumer.subscribe({ topic: 'order.created' });
consumer.run({
  eachMessage: async ({ message }) => {
    const order = JSON.parse(message.value!.toString());
    await sendConfirmationEmail(order);
  },
});

Architecture test (dependency-cruiser)

// .dependency-cruiser.js
module.exports = {
  forbidden: [
    {
      name: 'no-domain-to-infra',
      severity: 'error',
      from: { path: '^src/domain' },
      to: { path: '^src/infrastructure' },
    },
  ],
};

→ 매 layer violation 의 CI 에서 catch.

🤔 결정 기준

상황	추천
Solo / MVP	Monolith + Layered
Small team + complex business	Clean / Hexagonal
Large team + multi-domain	DDD + Microservices
Async / event-heavy	EDA
Variable load	Serverless
Legacy refactor	Strangler Fig (incremental)

기본값: Modular Monolith (DDD inside) → 매 scale 가 명확 후 Microservices.

🔗 Graph

• 부모: System-Design
• 변형: Layered-Architecture · Clean-Architecture · Hexagonal Architecture · Domain-Driven-Design · Microservices · Event-Driven-Architecture
• 응용: CQRS · Event Sourcing · Serverless · Strangler-Fig
• 검증: ADR · C4 Model (Architecture Documentation) · Dependency-Cruiser · ArchUnit
• Adjacent: SOLID · Design-Patterns · Anaemic Domain Model

🤖 LLM 활용

언제: 매 system design review. 매 codebase 의 first read. 매 architecture decision. 언제 X: 매 single-file script. 매 throwaway prototype.

❌ 안티패턴

• Premature microservices: 매 distributed monolith.
• Layered 의 strict 무시: 매 leak 의 부패.
• Clean architecture 의 small project: 매 over-engineering.
• DDD 의 simple CRUD: 매 boilerplate.
• EDA 의 sync expectation: 매 ordering bug.
• No ADR: 매 future-self 의 confusion.

🧪 검증 / 중복

• Verified (Uncle Bob, Eric Evans, Sam Newman).
• 신뢰도 A.
• Related: Domain-Driven-Design · Clean-Architecture · Microservices.

🕓 Changelog

날짜	변경
2026-05-08	Phase 1
2026-05-10	Manual cleanup — 5 styles + trade-off + Clean code + dependency-cruiser