Files

T

Antigravity Agent c24165b8bc refactor(topics): 멀티 에이전트용 지식 재편 — _Common(공통 기본기) + Domain_* 구조

에이전트 8종(대화형/프로그래머 C·S/디자이너/설계자/기획자/QA/PD/PM)에게
[공통 기본 능력 + 롤별 Specialty] 2층으로 지식을 주입하기 위한 재분류.
문서 내용·포맷은 무수정, 폴더 이동만 (6,372개 문서 수 보존 확인).

- Topic_Programming → Domain_Programming (내부 구조 보존)
- Topic_Graphic → Domain_Design
- Topic_Business → Domain_Product
- Topic_General → Domain_General
- _Common 신설: Math(구 Topic_Math_Specialty), Reasoning(구 General/From_Thinking & Reasoning),
  Reasoning_Creativity(구 General/From_창의성), Communication(Poetic_Blog_Writing + From_writing)
- 타 도메인의 From_* 폴더는 유지 (출처 표기일 뿐, 이미 도메인에 맞게 분류된 문서)
- 빈 폴더 정리 (memory/procedures)
- 에이전트→폴더 매핑은 workspace의 .astra/agent-knowledge-map.json (9개 에이전트)

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

2026-07-11 11:05:56 +09:00

5.1 KiB

Raw Blame History

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

title

소프트웨어 아키텍처 설계

매 한 줄

"매 architecture는 매 의사결정의 기록이며, 매 변경 비용을 결정한다". Bass/Clements/Kazman의 SEI 정의 이후, 매 architecture는 매 코드 자체가 아닌 매 component / connector / constraint의 집합으로 본다. 매 2026 modern view는 매 evolutionary architecture (Ford) — 매 fitness function 으로 매 architectural property 를 매 자동 검증.

매 핵심

매 4+1 View (Kruchten)

Logical: 매 도메인 객체 / 책임 분배.
Process: 매 runtime concurrency / 매 thread / 매 process.
Development: 매 module / 매 package 구조.
Physical: 매 deployment topology.
Scenarios (+1): 매 use case driven validation.

매 Quality Attributes (ISO/IEC 25010)

Performance: latency, throughput.
Scalability: horizontal / vertical 확장.
Availability: SLA, MTBF, MTTR.
Security: CIA triad.
Modifiability: 매 변경 cost.
Testability: 매 격리 가능성.

매 응용

C4 model 으로 매 stakeholder communication.
ADR (Architecture Decision Record) 으로 매 결정 추적.
Fitness function 으로 매 architectural drift 방지.

💻 패턴

ADR template

# ADR 0042: Adopt CQRS for Order service

## Status
Accepted (2026-05-10)

## Context
Read traffic 100x higher than write. Single Postgres table contention.

## Decision
Split into command (Postgres) + query (Read replica + Redis cache).
Event sourcing via Kafka.

## Consequences
+ Read scales independently.
- Eventual consistency window ~50ms.
- Two data models to maintain.

Fitness function (ArchUnit, Java)

@AnalyzeClasses(packages = "com.shop")
class ArchitectureTest {
    @ArchTest
    static final ArchRule domain_independent =
        noClasses().that().resideInAPackage("..domain..")
            .should().dependOnClassesThat().resideInAPackage("..infra..");

    @ArchTest
    static final ArchRule controllers_only_call_services =
        classes().that().resideInAPackage("..controller..")
            .should().onlyDependOnClassesThat()
            .resideInAnyPackage("..service..", "java..");
}

C4 Container diagram (Structurizr DSL)

workspace {
    model {
        user = person "Customer"
        shop = softwareSystem "Shop" {
            web = container "Web App" "React" "TypeScript"
            api = container "API" "Spring Boot"
            db = container "Database" "PostgreSQL 16"
        }
        user -> web "Browses"
        web -> api "Calls" "REST/JSON"
        api -> db "Reads/writes" "JDBC"
    }
}

Hexagonal Architecture (Python)

# domain/order.py — pure
class Order:
    def confirm(self) -> "Order": ...

# application/ports.py
class OrderRepo(Protocol):
    def save(self, o: Order) -> None: ...

# infra/postgres_order_repo.py — adapter
class PostgresOrderRepo:
    def save(self, o: Order) -> None:
        self.conn.execute("INSERT ...")

Event Storming output → bounded contexts

[Order Placed] → [Payment Authorized] → [Inventory Reserved] → [Order Confirmed]
   Order BC          Payment BC             Inventory BC           Order BC

매 결정 기준

상황	Approach
매 small team, simple domain	Modular monolith (Shopify-style)
매 high read/write asymmetry	CQRS
매 audit critical	Event sourcing
매 polyglot / independent scaling	Microservices
매 latency critical, ML inference	Service mesh + sidecar

기본값: 매 modular monolith → 매 evidence 기반 매 split.

🔗 Graph

부모: 아키텍처 패턴 지식
변형: Hexagonal Architecture · CQRS · Event Sourcing
응용: Microservices · Cloud_Native
Adjacent: Domain-Driven Design · ADR · C4 Model (Architecture Documentation)

🤖 LLM 활용

언제: 매 ADR 초안 / 매 trade-off 분석 / 매 quality attribute scenario 생성. 언제 X: 매 production-grade fitness function 의 자동 작성 — 매 human review 필수.

❌ 안티패턴

Big design up-front: 매 evolution 무시.
Architecture astronaut: 매 abstraction layer 과잉.
Distributed monolith: 매 microservice 의 분리 but 매 coupling 유지.
No fitness function: 매 drift 매 silently.

🧪 검증 / 중복

Verified (Bass/Clements/Kazman, Software Architecture in Practice 4e; Ford, Building Evolutionary Architectures 2e).
신뢰도 A.

🕓 Changelog

날짜	변경
2026-05-08	Phase 1
2026-05-10	Manual cleanup — 매 4+1, ADR, fitness function 패턴 추가

5.1 KiB Raw Blame History