@phuc1403/musketeer 0.1.0

package/template/.claude/skills/context-map/example.cml

@@ -0,0 +1,106 @@
+/* Canonical Context Map example for the context-map skill.
+ *
+ * Grammar reference: ./reference/Context Map.md
+ * Role combination rules: ./reference/Semantic Rules.md
+ *
+ * Shows all four relationship shapes (Partnership, Shared Kernel,
+ * Upstream-Downstream, Customer-Supplier) with the full attribute
+ * vocabulary so per-wall maps have a single place to copy from.
+ *
+ * This file is intended to compile clean against `cm validate -i <file>.cml`
+ * (Context Mapper CLI 6.12+). Every Bounded Context referenced in the
+ * ContextMap must also be declared as a `BoundedContext <Name>` below —
+ * forgetting that produces the Xtext linking error:
+ *   "Couldn't resolve reference to BoundedContext '<Name>'."
+ *   "The Bounded Context 'null' is not part of the Context Map."
+ */
+
+ContextMap DDDSampleContextMap {
+  type = SYSTEM_LANDSCAPE
+  state = AS_IS
+
+  contains CargoBookingContext, VoyagePlanningContext, LocationContext
+  contains ContractsContext, ClaimsContext
+  contains CustomerSelfServiceContext, CustomerManagementContext
+  contains PrintingContext, PolicyManagementContext
+
+  /* Shared Kernel (symmetric) --------------------------------------------
+   * Two contexts share a common subset of the model (a library, a package).
+   * Changes on either side need coordinated review.
+   */
+  CargoBookingContext [SK]<->[SK] VoyagePlanningContext : BookingVoyageRelationship {
+    implementationTechnology = "Java Library"
+  }
+
+  /* Partnership (symmetric) ----------------------------------------------
+   * Two contexts succeed or fail together. Joint planning, shared roadmap.
+   */
+  ContractsContext [P]<->[P] ClaimsContext : ContractClaimRelationship {
+    implementationTechnology = "Messaging"
+  }
+
+  /* Upstream-Downstream with OHS / PL / ACL ------------------------------
+   * Upstream publishes a stable, documented API in a Published Language.
+   * Downstream wraps incoming data in an Anti-Corruption Layer to keep
+   * upstream model leakage out of its own domain.
+   */
+  CargoBookingContext [D,ACL]<-[U,OHS,PL] LocationContext : CargoLocationRelationship {
+    implementationTechnology = "RESTful HTTP"
+    downstreamRights = VETO_RIGHT
+    exposedAggregates = Locations, Addresses
+  }
+
+  /* Customer-Supplier (asymmetric, downstream has influence) -------------
+   * Special case of upstream-downstream: downstream's priorities factor
+   * into upstream planning. Note: CF and OHS are NOT applicable here
+   * (semantic-rule errors). ACL is allowed but emits a semantic WARNING
+   * (rule #7 in Semantic Rules.md) — kept here to show the form.
+   */
+  CustomerSelfServiceContext [D,C,ACL]<-[U,S,PL] CustomerManagementContext : CustomerFrontendBackendRelationship {
+    implementationTechnology = "RESTful HTTP"
+    downstreamRights = OPINION_LEADER
+    exposedAggregates = Customers
+  }
+
+  /* Upstream-Downstream with CF (no ACL) ---------------------------------
+   * Downstream conforms to the upstream model wholesale — no translation.
+   * Cheap to integrate, but downstream becomes coupled to upstream changes.
+   */
+  PolicyManagementContext [D,CF]<-[U,OHS,PL] PrintingContext {
+    implementationTechnology = "SOAP"
+  }
+}
+
+/* ---------------------------------------------------------------------------
+ * Bounded Context declarations.
+ *
+ * Each name used above in `contains` and in relationship lines must resolve
+ * to a BoundedContext declaration somewhere in the file. Empty bodies are
+ * legal — declarations can stay minimal in a strategic-only map.
+ *
+ * Aggregates referenced by `exposedAggregates` MUST live inside the upstream
+ * BoundedContext of the relationship — see the LocationContext block (which
+ * owns Locations + Addresses, exposed to CargoBookingContext) and the
+ * CustomerManagementContext block (which owns Customers, exposed to
+ * CustomerSelfServiceContext).
+ * --------------------------------------------------------------------------- */
+
+BoundedContext CargoBookingContext
+BoundedContext VoyagePlanningContext
+
+BoundedContext LocationContext {
+  Aggregate Locations
+  Aggregate Addresses
+}
+
+BoundedContext ContractsContext
+BoundedContext ClaimsContext
+
+BoundedContext CustomerSelfServiceContext
+
+BoundedContext CustomerManagementContext {
+  Aggregate Customers
+}
+
+BoundedContext PrintingContext
+BoundedContext PolicyManagementContext

package/template/.claude/skills/context-map/reference/Aggregate/Aggregate.md

@@ -0,0 +1 @@
+ An aggregate can further contain Services, Resources, Consumers and SimpleDomainObjects (Entities, Value Objects, Domain Events, etc.)

package/template/.claude/skills/context-map/reference/Bounded Context/Bounded Context.md

@@ -0,0 +1,41 @@
+```cml
+BoundedContext CustomerManagementContext implements CustomerManagementDomain {
+  type = FEATURE
+  domainVisionStatement = "The customer management context is responsible for ..."
+  implementationTechnology = "Java, JEE Application"
+  responsibilities = "Customers", "Addresses"
+  knowledgeLevel = CONCRETE
+
+  Module addresses {
+    Aggregate Addresses {
+      Entity Address {
+        String city
+      }
+    }
+  }
+  Aggregate Customers {
+    Entity Customer {
+      aggregateRoot
+
+      - SocialInsuranceNumber sin
+      String firstname
+      String lastname
+      - List<Address> addresses
+    }
+  }
+}
+```
+
+Note: Bounded Context names must be unique within your CML model.
+
+[[implements]]
+[[refines]]
+[[domainVisionStatement]]
+[[implementationTechnology]]
+[[responsibilities]]
+[[Domain-Driven Design/Context Map/Bounded Context/type]]
+[[knowledgeLevel]]
+[[businessModel]]
+[[evolution]]
+[[realizes]]
+[[Bounded Context Relationship]]

package/template/.claude/skills/context-map/reference/Bounded Context/businessModel.md

@@ -0,0 +1,6 @@
+https://github.com/ddd-crew/bounded-context-canvas
+- UNDEFINED
+- REVENUE
+- ENGAGEMENT
+- COMPLIANCE
+- COST_REDUCTION

package/template/.claude/skills/context-map/reference/Bounded Context/domainVisionStatement.md

@@ -0,0 +1,3 @@
+The `domainVisionStatement` keyword describes the vision statement of your bounded context, according to the DDD Domain Vision Statement pattern. https://contextmapper.org/docs/domain-vision-statement/
+
+Can be used in a [[Domain-Driven Design/Context Map/Bounded Context/Bounded Context|Bounded Context]], a [[Domain]], and a subdomain.

package/template/.claude/skills/context-map/reference/Bounded Context/evolution.md

@@ -0,0 +1,6 @@
+https://github.com/ddd-crew/bounded-context-canvas
+- UNDEFINED
+- GENESIS
+- CUSTOM_BUILT
+- PRODUCT
+- COMMODITY

package/template/.claude/skills/context-map/reference/Bounded Context/implementationTechnology.md

@@ -0,0 +1 @@
+The `implementationTechnology` adds information about how the corresponding bounded context is implemented. Note that this attribute does not correspond to any DDD pattern.

package/template/.claude/skills/context-map/reference/Bounded Context/implements.md

@@ -0,0 +1 @@
+The `implements` keyword specifies which domain or subdomains are implemented by this bounded context. Behind the `implements` keyword you can either reference a list of subdomains (comma-separated) or one top-level domain.

package/template/.claude/skills/context-map/reference/Bounded Context/knowledgeLevel.md

@@ -0,0 +1,5 @@
+The `knowledgeLevel` keyword defines the knowledge level of the bounded context which can be one of the following two:
+- `CONCRETE`
+- `META`
+
+Also supports [[Aggregate]]

package/template/.claude/skills/context-map/reference/Bounded Context/realizes.md

@@ -0,0 +1,9 @@
+If your bounded context is of the type TEAM, you can specify which bounded context the team implements by using the `realizes` keyword. The following example illustrates this:
+
+```cml
+BoundedContext CustomersBackofficeTeam implements CustomerManagementDomain realizes CustomerManagementContext {
+  type = TEAM
+  domainVisionStatement = "This team is responsible for implementing ..."
+}
+```
+

package/template/.claude/skills/context-map/reference/Bounded Context/refines.md

@@ -0,0 +1,10 @@
+The `refines` keyword allows you to create some kind of an inheritance hierarchy in case one bounded context can be seen as a refinement of another bounded context.
+However, note that this is only a modeling information and generators do not recursively resolve the domain model (Aggregates, etc.) of refined bounded contexts.
+
+```cml
+BoundedContext ContextMapperTool refines StrategicDomainDrivenDesignContext {
+  type FEATURE
+  domainVisionStatement "Context Mapper provides a formal way to model strategic DDD Context Maps."
+  implementationTechnology "Java, Eclipse"
+}
+```

package/template/.claude/skills/context-map/reference/Bounded Context/responsibilities.md

@@ -0,0 +1,26 @@
+With the `responsibilities` keyword you are allowed to specify the responsibilities of the bounded context, according to the DDD Responsibility Layers pattern.
+
+Can be used on [[Domain-Driven Design/Context Map/Bounded Context/Bounded Context|Bounded Context]]s and [[Aggregate]]s to specify their responsibilities.
+
+```cml
+BoundedContext CustomerManagementContext implements CustomerManagementDomain {
+  type = FEATURE
+  domainVisionStatement = "The customer management context is responsible for ..."
+  implementationTechnology = "Java, JEE Application"
+  responsibilities = "Customers", "Addresses"
+}
+
+Aggregate Customers {
+  responsibilities = "Customers", "Addresses"
+  
+  Entity Customer { 
+    aggregateRoot
+    
+    - SocialInsuranceNumber sin
+    String firstname
+    String lastname
+    - List<Address> addresses
+  }
+}
+```
+

package/template/.claude/skills/context-map/reference/Bounded Context/type.md

@@ -0,0 +1,23 @@
+# Bounded Context Type
+
+The `type` provides an indicator for which reason a bounded context may have been evolved. It further allows you to specify from which viewpoint you describe your bounded contexts.
+
+- `FEATURE`: analysis or early design abstractions, taking a functional scenario view
+  - For example, everything that is related to customer management in an insurance scenario: create customer, update customer, update customer address, etc.
+- `APPLICATION`: represent more elaborated, logical designs and implementation views
+  - For example: a self-service frontend application for the customers, a backend system to manage the customers and contract, etc.
+  - An application typically encompasses multiple functional features. In a (micro-)service-oriented architecture, each (micro-)service can be seen as an application.
+- `SYSTEM`: contexts add a more physical, process- and deployment-oriented view
+  - Examples for systems: a single page application for the frontend, a Spring Boot application that realizes the domain logic, an Oracle database that holds the data, etc.
+  - An application typically consists of multiple systems.
+- `TEAM`: allows you to specify which team is implementing which bounded contexts
+  - For example: multiple teams work on different parts of the software: customer frontend team, customer backend\_ team, contracts team, etc.
+
+## Example: The "Returns" Domain
+
+1. Feature Context: We identify "Return Eligibility." This is purely a business concept: rules checking if an item is within the 30-day window and undamaged. It doesn't imply a server or a database yet.
+2. Application Context: We design the "Returns Service." This is a deployable logical unit (a Microservice) that handles eligibility, printing labels, and refund triggering. It encapsulates the "Return Eligibility" feature.
+3. System Context: When deploying, the "Returns Service" is actually split into two physical pieces:
+   - "Returns Backend API" (Spring Boot container).
+   - "Returns Dashboard" (React SPA for warehouse workers). These are two separate SYSTEM contexts.
+1. Team Context: All of the above is owned by "Team After-Sales", a squad of 6 developers.

package/template/.claude/skills/context-map/reference/Bounded Context Relationship/Anticorruption Layer.md

@@ -0,0 +1,5 @@
+```cml
+DebtCollection [D,ACL]<-[U,OHS,PL] PrintingContext {
+  implementationTechnology = "SOAP"
+}
+```

package/template/.claude/skills/context-map/reference/Bounded Context Relationship/Bounded Context Relationship.md

@@ -0,0 +1,13 @@
+symmetric relationships
+- [[Partnership (P)]]
+- [[Shared Kernel (SK)]]
+asymmetric relationships
+- Upstream-Downstream (generic)
+- [[Customer-Supplier (C-S)]], a special form of an Upstream-Downstream relationship
+
+```cml
+CargoBookingContext [D]<-[U] LocationContext
+
+// A colon at the end assigns a relationship a name
+LocationContext Upstream-Downstream CargoBookingContext : CargoLocationRelationship
+```

package/template/.claude/skills/context-map/reference/Bounded Context Relationship/Conformist.md

@@ -0,0 +1,5 @@
+```cml
+PolicyManagementContext [D,CF]<-[U,OHS,PL] CustomerManagementContext {
+  implementationTechnology = "RESTful HTTP"
+}
+```

package/template/.claude/skills/context-map/reference/Bounded Context Relationship/Customer-Supplier (C-S).md

@@ -0,0 +1,23 @@
+The customer-supplier relationship is a special case of a upstream-downstream relationship
+
+A customer-supplier relationship is an upstream-downstream relationship where the downstream priorities factor into upstream planning.
+The upstream team may succeed interdependently of the fate of the downstream team and therefore the needs of the downstream have to be addressed by the upstream. They interact as customer and supplier.
+
+```cml
+CustomerSelfServiceContext [D,C]<-[U,S] CustomerManagementContext
+
+CustomerSelfServiceContext Customer-Supplier CustomerManagementContext
+
+CustomerSelfServiceContext [C]<-[S] CustomerManagementContext
+
+CustomerSelfServiceContext [D,C,ACL]<-[U,S,PL] CustomerManagementContext : Customer_Frontend_Backend_Relationship { // Relationship name is optional
+  implementationTechnology = "RESTful HTTP"
+  
+CustomerSelfServiceContext[ACL] Customer-Supplier [PL]CustomerManagementContext
+}
+```
+
+The [[Conformist]] pattern is not applicable in a Customer/Supplier relationship.
+The [[Open Host Service]] pattern is not applicable in a Customer/Supplier relationship.
+The [[Anticorruption Layer]] pattern can be used in a Customer/Supplier relationship, but this leads to contradictions with the original pattern definition according to our understanding.
+The usage of Anticorruption Layer in a Customer/Supplier relationship produces a Warning only.

package/template/.claude/skills/context-map/reference/Bounded Context Relationship/Open Host Service.md

@@ -0,0 +1,5 @@
+```cml
+PrintingContext [U,OHS]->[D,ACL] PolicyManagementContext {
+  implementationTechnology = "SOAP"
+}
+```

package/template/.claude/skills/context-map/reference/Bounded Context Relationship/Partnership (P).md

@@ -0,0 +1,14 @@
+```cml
+ContractsContext [P]<->[P] ClaimsContext {
+  implementationTechnology = "Messaging"
+}
+
+ContractsContext Partnership ClaimsContext {
+  implementationTechnology = "Messaging"
+}
+
+// With a colon it is possible (optionally) to add a relationship name to the specification
+ContractsContext [P]<->[P] ClaimsContext : ContractClaimRelationship {
+  implementationTechnology = "Messaging"
+}
+```

package/template/.claude/skills/context-map/reference/Bounded Context Relationship/Published Language.md

@@ -0,0 +1,5 @@
+```cml
+PolicyManagementContext [D,CF]<-[U,OHS,PL] CustomerManagementContext {
+  implementationTechnology = "RESTful HTTP"
+}
+```

package/template/.claude/skills/context-map/reference/Bounded Context Relationship/Shared Kernel (SK).md

@@ -0,0 +1,13 @@
+```cml
+CargoBookingContext [SK]<->[SK] VoyagePlanningContext {
+  implementationTechnology = "Java Library"
+}
+
+argoBookingContext Shared-Kernel VoyagePlanningContext {
+  implementationTechnology = "Java Library"
+}
+
+CargoBookingContext Shared-Kernel VoyagePlanningContext : BookingVoyageRelationship {
+  implementationTechnology = "Java Library"
+}
+```

package/template/.claude/skills/context-map/reference/Context Map.md

@@ -0,0 +1,63 @@
+A context map contains bounded contexts and defines their relationships.
+
+```cml
+ContextMap DDDSampleContextMap {
+  type SYSTEM_LANDSCAPE
+  state AS_IS
+//  type = SYSTEM_LANDSCAPE
+//  state = AS_IS
+
+  contains CargoBookingContext, VoyagePlanningContext, LocationContext
+//  contains CargoBookingContext
+//  contains VoyagePlanningContext
+//  contains LocationContext
+
+  CargoBookingContext [SK]<->[SK] VoyagePlanningContext
+}
+```
+A context map can be of one of the following `type`s:
+- `SYSTEM_LANDSCAPE` represents the default type of context map in which the bounded contexts represent software systems (or applications).
+- `ORGANIZATIONAL` map (or ‘team map’) illustrates the relationships between teams.
+
+The `state` expressing whether the given context map represents the current or a desired state:
+- `AS_IS`: Current State
+- `TO_BE`: Desired State
+[[Bounded Context Relationship]]
+# Relationship Roles
+You can further specify the relationship roles such as Open Host Service (OHS) or Anti-Corruption Layer (ACL) within the brackets. Roles must always be specified behind the U (upstream) and the D (downstream) if they are not omitted.
+
+```cml
+VoyagePlanningContext [D,ACL]<-[U,OHS,PL] LocationContext
+```
+
+Upstream roles:
+-  Open Host Service (OHS)
+-  Published Language (PL)
+The patterns OHS and PL can only be implemented by the upstream context in an upstream-downstream relationship. The upstream context always provides and exposes a certain functionality. The downstream context uses and consumes this services and does not expose parts of his/her own domain model. If this was the case and the upstream used this functionality, the definition that the upstream is independent of the downstream would be contradicted.
+
+Downstream roles:
+- Conformist (CF) 
+- Anticorruption Layer (ACL).
+# Relationship Attributes
+`implementationTechnology`: Within the body of the declaration, it is possible to specify the implementation technology used to realize this relationship:
+
+`downstreamRights`: defines which governance rights, and therefore which influence, the downstream has on the upstream within the specified relationship:
+The possible governance rights values are:
+- INFLUENCER
+- OPINION_LEADER
+- VETO_RIGHT
+- DECISION_MAKER
+- MONOPOLIST
+
+`exposedAggregates`: offers the possibility to declare which Aggregates of the upstream bounded context are exposed in order to realize this relationship. The attribute takes a comma-separated list of references to Aggregates. The referenced Aggregates must be part of the upstream context of the relationship.
+
+```cml
+VoyagePlanningContext [D,ACL]<-[U,OHS,PL] LocationContext {
+    implementationTechnology = "RESTful HTTP"
+    downstreamRights = VETO_RIGHT
+    exposedAggregates = Customers, Addresses
+}
+```
+
+[[Bounded Context]]
+[[Semantic Rules]]

package/template/.claude/skills/context-map/reference/Domain/Domain.md

@@ -0,0 +1,30 @@
+Domains are defined on the root level of a CML file.
+They provide a container to specify all subdomains which are then referenced on a bounded context with the `implements` keyword.
+A bounded context can also implement the compete domain.
+
+```cml
+/* Syntax example: Domain and Subdomains */
+Domain Insurance {
+  domainVisionStatement = "Insurance domain vision statement ..."
+
+  Subdomain CustomerManagementDomain {
+    type = CORE_DOMAIN
+    domainVisionStatement = "Subdomain managing everything customer-related."
+
+    Entity Customer {
+      String firstname
+      String familyname
+    }
+
+    /* Add more entities ... */
+  }
+
+  Subdomain ContractManagementDomain {}
+
+  /* Add more subdomains ... */
+}
+```
+[[domainVisionStatement]]
+[[Domain-Driven Design/Context Map/Domain/type|type]]
+[[supports]]
+

package/template/.claude/skills/context-map/reference/Domain/supports.md

@@ -0,0 +1,34 @@
+The `supports` keyword specifies which user requirements a Subdomain implements.
+
+```cml
+/* Syntax example for Subdomain that supports specific user requirements: */
+Domain Insurance {
+  domainVisionStatement = "Insurance domain vision statement ..."
+
+  Subdomain CustomerManagementDomain supports CreateCustomers, CreateCustomerAddresses {
+    type = CORE_DOMAIN
+    domainVisionStatement = "Subdomain managing everything customer-related."
+
+    Entity Customer {
+      String firstname
+      String familyname
+    }
+  }
+
+}
+
+UserStory CreateCustomers {
+  As an "Insurance Employee"
+    I want to "create" a "Customer" with its "firstname", "lastname"
+  so that "I am able to manage the customers data and offer them insurance contracts."
+}
+
+UserStory CreateCustomerAddresses {
+  As an "Insurance Employee"
+    I want to "create" an "Address" for a "Customer"
+    I want to "update" an "Address" for a "Customer"
+  so that "I am able to manage the customers addresses."
+}
+```
+
+[[UserStory]]

package/template/.claude/skills/context-map/reference/Domain/type.md

@@ -0,0 +1,3 @@
+CORE_DOMAIN
+SUPPORTING_DOMAIN
+GENERIC_SUBDOMAIN

package/template/.claude/skills/context-map/reference/Semantic Rules.md

@@ -0,0 +1,33 @@
+The following semantic rules are either implicitly given by the domain model on which the language is based (see above), or enforced by corresponding semantic checkers.
+
+Note that the model and the semantic rules express how we understand the DDD patterns and how they can be combined, and how we applied DDD on projects ourselves. Rationale: the literature is somewhat ambiguous.
+
+# 1: Permitted Upstream Roles
+The patterns OHS and PL can only be implemented by the upstream context in an upstream-downstream relationship. The upstream context always provides and exposes a certain functionality. The downstream context uses and consumes this services and does not expose parts of his/her own domain model. If this was the case and the upstream used this functionality, the definition that the upstream is independent of the downstream would be contradicted.
+
+# 2: Permitted Downstream Roles
+The patterns ACL and CF can only be applied by the downstream context in an upstream-downstream relationship. These patterns solve a downstream problem, namely how to deal with a dependency to another context. It is always the downstream context that has to integrate the upstream model.
+
+# 3: Protect or Conform
+The patterns ACL and CF cannot be applied jointly, but provide alternatives. The downstream either conforms (CF) or protects itself with an ACL.
+
+# 4: Integrity of Symmetric Relationships
+The patterns OHS, PL, ACL and CF are not applicable in symmetric relationships (Partnership and Shared Kernel), since doing so would lead to contradictions with the pattern definitions. In a Shared Kernel relationship, the two contexts communicate over shared code such as a library. Both contexts manage the shared code together, which clearly contradicts with the mentioned four pattern definitions. An OHS indicates a directed provider/consumer behavior which is not the case here. There is no need for a common inter-context language (PL), since the two contexts simply share the same model. An ACL is not required either since the two participants share the model anyway. And neither context has to conform to the model of the other since it is one shared model. In a Partnership relationship both contexts depend on each other, which means they can only succeed or fail together.
+
+# 5: Customer vs. Conformist
+The CF pattern is not applicable within a customer-supplier relationship. In a customer-supplier relationship the customer has influence on the supplier and can at least negotiate regarding priorities of the requirements and the implementation. A conformist in contrast has no influence and simply decides to conform to what the upstream provides.
+
+# 6: Generic vs. Custom Service
+The OHS pattern is not applicable within a customer-supplier relationship. Whereas the customer-supplier pattern implies that the involved teams work closely together, meaning that the upstream respects the downstreams requirements in his planning sessions, the OHS pattern indicates that the upstream team decides to implement one API in a one for all approach. This is contradictory since it is unlikely that such an upstream implementing an OHS is able to have a close customer-supplier relationship with all its downstreams. From personal practical experience a customer-supplier relationship leads to individual requirements of single customers. As soon as the supplier implements a customer-specific API feature it is by pattern definition no longer an OHS.
+
+# 7: Protect or Cooperate
+The ACL pattern should not be used within a customer-supplier relationship. Changes of the supplier should be in-sync with the needs of the customer. Protection should be unnecessary. Note that this is only a soft rule since the combination is possible but not common. Our tool issues a warning rather than an error message if it detects a violation of the rule.
+
+# 8: ORGANIZATIONAL Context Maps
+A context map of the type ORGANIZATIONAL (team map), can only contain bounded contexts of the type TEAM. This checker provides consistency within team maps. On such a map a bounded context represents a team and not a classical bounded context such as a system, feature or application.
+
+# 9: SYSTEM LANDSCAPES
+A bounded context of the type TEAM can not be contained by a context map of the type SYSTEM_LANDSCAPE. This checker provides consistency within context maps. Can be seen as the inverse case of rule #8.
+
+# 10: Teams realize Bounded Contexts
+Only teams can realize bounded contexts. This checker ensures that the realize keyword can only be used for bounded contexts of the type TEAM. The keyword is added to the language definition in order to reference the bounded contexts a team is realizing. It would not make sense for a classical bounded context (system, feature or application).