update skills

.agents/skills/domain-driven-design/references/bounded-contexts.md

@@ -0,0 +1,32 @@
+# Bounded Contexts and Context Mapping
+
+A bounded context defines where a domain model and its language apply. It is not automatically a microservice, package, or team-sized deployment.
+
+## Find a real boundary
+
+Look for differing business meanings, rules, ownership, or change lifecycles. Check concrete scenarios and existing ADRs. A single context may be correct; excessive translation between closely related concepts can signal an unnecessary split.
+
+For a requested context map, show the relevant contexts, ownership, upstream/downstream relationships, shared contracts, and any translation. Avoid mapping unrelated systems just to complete a catalog.
+
+## Choose the relationship
+
+| Pattern                                | Useful when                                                        | Cost to make explicit                              |
+| -------------------------------------- | ------------------------------------------------------------------ | -------------------------------------------------- |
+| Shared kernel                          | Closely collaborating owners genuinely share a small model         | Coordinated changes and tests                      |
+| Customer–supplier                      | The upstream team can accommodate downstream needs                 | Planning and contract dependency                   |
+| Conformist                             | Accepting the upstream model is cheaper and safe for this use case | Coupling to upstream semantics                     |
+| Anti-corruption layer                  | Foreign semantics would distort local business rules               | Translation and its tests                          |
+| Open host service / published language | Several consumers need a documented shared contract                | Contract ownership and actual external obligations |
+| Separate ways                          | Integration costs more than limited duplication                    | Separate implementations and knowledge             |
+| Partnership                            | Models must evolve together                                        | Ongoing coordination                               |
+| Big ball of mud                        | Existing entanglement needs to be named during an assessment       | A diagnosis, not a target design                   |
+
+Translation can live in an existing adapter or mapper; it does not require a facade/adapter/translator class hierarchy. Validate untrusted external data even when adopting the upstream model directly.
+
+## Changes and external constraints
+
+Preserve actual external contracts that the task cannot replace. Legacy coexistence patterns apply to a genuinely external system that must remain available, not to this application's disposable development model.
+
+For internal model changes, follow [the development lifecycle](../../../../AGENTS.md#development-data-lifecycle): replace obsolete schemas/contracts, update callers and tests together, and reseed rather than introducing compatibility paths.
+
+Explain a proposed split or merge through its effect on language, invariant ownership, coupling, and coordination. Do not reorganize teams, deploy services, or modify contracts merely because a map was requested.