Microservice-Grenzen ziehen

Help me draw service boundaries for this domain. Apply DDD thinking: aggregates first, services second.

Input from me:
- Domain description and core workflows
- Team structure (if relevant)
- Current pains (monolith hot spots, deploy coupling, data coupling)

Output:
1. BOUNDED CONTEXTS - name each, with 1-sentence purpose + main entities
2. AGGREGATES - within each context, which aggregate roots, what invariants they enforce
3. INTEGRATION - between contexts: sync API, async event, shared DB (anti-pattern - flag if needed), anticorruption layer needed
4. EVENTS (if event-driven is on the table) - which domain events cross boundaries
5. TEAM FIT - does this align with Team Topologies (stream-aligned, platform, complicated-subsystem)? Flag mismatches.
6. MIGRATION ORDER - if decomposing a monolith: which context to carve out first and why (usually: least coupled, clearest value)

Rules:
- Do not split by technical layer ("user-service", "auth-service") - split by business capability
- Name ubiquitous-language terms, not generic nouns ("Catalog", not "product-service")
- A service whose sole purpose is to wrap a single table is probably not a service
- Flag "distributed monolith" risk when calls ping-pong between contexts

Domain description:
[PASTE]

Wann nutzen

Bevor aus einem Monolith ein Micro-Zoo wird. Der Team-Fit-Check verhindert, dass Services entstehen, für die keine Ownership da ist.

Use-Cases

• Bestehender Monolith: wo rausschneiden?
• Neues System: sauber in Contexts aufteilen.
• Team-Skalierung: Services pro Team sauber zuschneiden.

Getestet mit

• Claude Opus 4.7