@phuc1403/musketeer 0.9.0 → 0.10.0

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

@@ -1,13 +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"
-}
+```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

@@ -1,63 +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]]
+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

@@ -1,30 +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]]
-
+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

@@ -1,34 +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."
-}
-```
-
+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

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

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

@@ -1,33 +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
+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).