Use when designing or reviewing domain-model accessors that expose internal state for persistence, serialization, tests, or framework integration. Applies the breachEncapsulationOf naming pattern so unavoidable getters are visibly treated as encapsulation breaches, not casual domain APIs. Trigger for getter naming…
Use only when the user explicitly asks for Clean Architecture design, implementation, or review. Applies a domain, use case, interface adapter, and infrastructure layer model, with persistence and RPC adapters outside the domain and use-case rules. Do not trigger for generic architecture advice, hexagonal…
Use when CQRS changes aggregate boundaries or state shape. Helps reduce oversized command aggregates by moving read concerns to read models, keeping only command-decision state in aggregates, and using events for state transitions. Trigger for large aggregates, heavy command updates, aggregates containing query-only…
Use when explaining why CQRS often needs event sourcing or durable events for reliable command-to-query synchronization. Covers calculated value sync, database trigger limits, polling scalability, double commits, and making events the source of truth. Trigger for CQRS synchronization, read-model update strategy, CQRS…
Use when evaluating whether CQRS is worth adopting, especially tradeoffs among consistency, availability, scalability, operational complexity, and event sourcing. Trigger for read/write separation decisions, eventual consistency concerns, CQRS architecture review, or choosing between a unified model and CQRS.
Use when reviewing or designing transaction boundaries that touch DDD aggregates. Detects the anti-pattern of updating multiple aggregates in one transaction and replaces it with one-aggregate transactions plus eventual consistency, domain events, sagas, or process managers. Trigger for cross-aggregate transactions…
Use when a use case wants to check another aggregate's state before changing the current aggregate. Helps separate true invariants from policies, detect Saga misuse, reason about CQRS/Event Sourcing lookup limits, and decide whether inconsistent data is acceptable. Trigger for cross-aggregate validation, checking…
Use for choosing and applying DDD building blocks: value objects, entities, aggregates, domain services, repositories, factories, and domain events. Trigger for domain modeling, entity versus value object decisions, aggregate boundaries, domain service placement, or implementing a domain model from requirements.
Use when analyzing existing non-DDD or legacy code to propose DDD domain models with aggregates, local entities, value objects, domain services, invariants, and pseudocode. Trigger for extracting a domain model from code, redesigning legacy code with DDD, finding aggregates, or proposing domain boundaries from an…
Use when planning a DDD implementation flow that starts from the domain model and tests before infrastructure. Covers test-first domain modeling, in-memory repositories, use cases, and delaying persistence/framework choices. Trigger for starting from the domain model, TDD with DDD, in-memory repository design…
Use when replacing raw primitive values with validated domain primitives or value objects so invalid domain states cannot be represented. Covers always-valid construction, smart constructors, parse-don't-validate, and avoiding primitive obsession. Trigger for domain primitive design, validated IDs, email/money/range…
Use when designing or reviewing repositories in DDD. Treats repositories as collection-like access to aggregate roots, not generic DAO layers, and separates query/read-model concerns from command persistence. Trigger for repository interfaces, aggregate persistence, save/load semantics, query placement, ORM leakage…
Use when deciding where repository interfaces and implementations belong in layered, Clean Architecture, or DDD projects. Emphasizes that aggregates should not depend on repositories and that application/use-case layers own repository orchestration. Trigger for repository-in-domain questions, repository package…
Use when deciding whether a primitive value should become a domain-specific type or value object. Balances primitive obsession against value-object obsession using risk, invariants, behavior, and cost. Trigger for wrapping strings/ints/UUIDs, value object decisions, too many tiny types, or whether a primitive is good…
Use when clarifying software abnormal-state terminology such as error, defect, fault, failure, bug, incident, and exception. Helps choose handling, testing, and mitigation strategies from precise classification. Trigger for error terminology, fault versus failure, defect versus bug, abnormal-state design, failure…
Use when designing or reviewing error handling across domain logic, application services, and infrastructure. Uses recoverability to choose typed errors, Result/Either, exceptions, retries, and logging. Trigger for improving error handling, Result types, exception design, recoverable errors, domain errors, or…
Use when wrapping collections in a domain-specific class to centralize collection rules, invariants, and behavior. Trigger for scattered list logic, collection wrappers, raw Order lists becoming Orders, enforcing collection invariants, or reviewing collection-heavy domain code.
Use when a TypeScript project adopts the class-free, functional domain modeling style: type-alias contracts instead of interface, factory functions with closure state instead of class, companion objects via type+namespace declaration merging, branded types with smart constructors, and discriminated-union Result/error…
Use when deciding whether similar code should be deduplicated. Prioritizes shared intent and change reason over textual similarity, avoiding harmful DRY abstractions when code looks alike but changes for different reasons. Trigger for duplicate code, DRY decisions, merging functions, common helpers, or refactoring…
Use when reviewing or refactoring object coupling caused by train-wreck call chains and knowledge of nested internals. Applies the Law of Demeter / Principle of Least Knowledge to move behavior closer to the owning object. Trigger for chained calls, dot chains, train wrecks, high coupling, Feature Envy, or reducing…
Use when redesigning package or module structure for messy codebases, large modules, dependency problems, or new project structure. Applies information hiding, change reasons, dependency direction, and release boundaries. Trigger for package structure review, module dependencies, file placement, circular dependency…
Use when replacing validation that discards information with parsing that returns a typed, validated value. Helps enforce invariants through the type system and reduce shotgun parsing. Trigger for validation refactors, type-safe inputs, invalid-state prevention, reducing Maybe/nullable checks, or converting validators…
★not rated 8 13d agoA67 tokens
originalApache-2.0
At most 3 mods per repository are shown here, and a mod shipped inside a plugin is left to that plugin's page — the rest are on their repository pages: