Onboarding guide

18. ADC Conference - Application & Use Cases

What this chapter covers. This is the application layer of the Conference module, the largest single application assembly in the codebase (this group covers 303 entries in the type map, 302 distinct names, since two private StatusBucket enums share a name in different decision-support slices). It sits between the REST/gRPC edge (G20, Conference API & gRPC) and the domain aggregates (G17, Conference Domain), and it is where the conference's use cases actually live: create an event, publish it, add a room, a speaker, a sponsor or a social activity, import the whole agenda from Sessionize.com, export the schedule as an .ics calendar, answer "what is happening right now", and run the AI-assisted analytics that help organizers decide which session proposals to accept. One slice cuts across several of those reads: the public-visibility projection that keeps non-published events, non-accepted sessions, their speakers, their rooms, their sponsors and their activities out of an unprivileged reader's results (BR-108 / BR-49 / BR-239). It is resolved in one place by PublicConferenceVisibility over the shared PublicSessionStatusSpecification allow-list, and nine GetPublic*Filter handlers (activities, rooms, event speakers, sessions, session category items, session speakers, speakers, speaker category items, and sponsors) turn its id lists into specifications the Conference controllers apply. Everything here is engine-agnostic and framework-light: it depends on the abstractions introduced by MMCA.Common.Application (handlers, handler bases, mappers, validators, query services, navigation populators) and on the Conference domain, but never on EF Core, ASP.NET, or a broker SDK directly. Read the primer's tour of CQRS and Vertical Slice first; this chapter shows those styles at full scale in one module.

The vertical-slice anatomy of a use case

Open any feature folder under Sessions/UseCases/, Events/UseCases/, Speakers/UseCases/, Sponsors/UseCases/, Activities/UseCases/, Categories/UseCases/, or Questions/UseCases/ and you will find the same cohesive slice: a command or query record, its handler, its FluentValidation validator, and (for creates) a request record plus a request mapper, all co-located. Adding a feature means adding a folder, not threading an edit through horizontal Services/, Validators/, and Repositories/ directories. This is the Vertical Slice discipline made physical. [Rubric §5, Vertical Slice] assesses whether a feature is one navigable unit rather than scattered horizontally, and the folder layout is the evidence.

A command mutates and returns a Result; a query is side-effect-free and returns a Result<TDTO>. Both implement the Common contracts ICommandHandler<in TCommand, TResult> and IQueryHandler<in TQuery, TResult>, so every handler in this assembly flows through the same decorator pipeline (Logging, Caching, Transactional, then the handler) without knowing it exists. Commands that change cached read data implement ICacheInvalidating and publish the aggregate prefix the pipeline evicts (MMCA.ADC.Conference.Application/Sessions/UseCases/Update/UpdateSessionCommand.cs:16-20, MMCA.ADC.Conference.Application/Events/UseCases/Update/UpdateEventCommand.cs:16-20). Four commands must be atomic across several writes and additionally implement ITransactional: the Sessionize refresh (MMCA.ADC.Conference.Application/Events/UseCases/RefreshFromSessionize/RefreshFromSessionizeCommand.cs:13, which also carries IFeatureGated with the SessionizeIntegration flag at :19), the two speaker link commands (MMCA.ADC.Conference.Application/Speakers/UseCases/LinkUser/LinkUserToSpeakerCommand.cs:13, MMCA.ADC.Conference.Application/Speakers/UseCases/UnlinkUser/UnlinkUserFromSpeakerCommand.cs:12), and BatchAddSessionQuestionAnswersCommand, which submits a whole feedback form so a partially applied form can never be observed (MMCA.ADC.Conference.Application/Sessions/UseCases/BatchAddSessionQuestionAnswers/BatchAddSessionQuestionAnswersCommand.cs:22-28). Exactly one read opts into caching: GetNowNextQuery implements IQueryCacheable with a 30-second TTL (MMCA.ADC.Conference.Application/Sessions/UseCases/NowNext/GetNowNextQuery.cs:38) and a cache key built under the Session aggregate prefix, so session writes evict it (GetNowNextQuery.cs:26-35). The controller injects the handler interface and calls HandleAsync; the concrete type is invisible to it. [Rubric §6, CQRS & Event-Driven] assesses a clean command/query split through well-defined handler boundaries: this module is the canonical demonstration, dozens of single-responsibility handlers, each one slice wide, all dispatched uniformly.

The CRUD-shaped handlers do not spell out the load-validate-persist-map dance any more; they fill in the holes of a framework base class. CreateActivityHandler is the smallest complete example: it derives from CreateEntityHandlerBase<TCreateRequest, TEntity, TIdentifierType, TEntityDTO> closed over the activity types and overrides exactly one member, the module-vocabulary log line (MMCA.ADC.Conference.Application/Activities/UseCases/Create/CreateActivityHandler.cs:20-24); the base runs the IEntityRequestMapper<TEntity, TCreateRequest, TIdentifierType> (validator plus the domain Create(...) factory, returning Result<TEntity>), persists through IUnitOfWork, and maps back with an IEntityDTOMapper<TEntity, TEntityDTO, TIdentifierType>. CreateEventHandler, CreateSpeakerHandler, CreateSponsorHandler, CreateQuestionHandler and CreateConferenceCategoryHandler follow the identical shape. State transitions use the sibling base: PublishEventHandler derives from MutateEntityHandlerBase<TCommand, TEntity, TIdentifierType> and supplies three things, the id to load (MMCA.ADC.Conference.Application/Events/UseCases/Publish/PublishEventHandler.cs:19), the client's row-version token so a decision taken against a stale view fails the save and answers 412 Precondition Failed rather than silently winning (:21-25, ADR-035), and the mutation itself, a one-line delegation to Event.Publish() (:28-32). The business rule ("an event's end date cannot precede its start date") lives in the domain factory and the invariant classes, never here.

DeleteEventHandler is the one delete that is not the generic framework handler: it eagerly loads the event's owned children (Rooms, EventSpeakers, EventQuestionAnswers, MMCA.ADC.Conference.Application/Events/UseCases/Delete/DeleteEventHandler.cs:28-33), then the event's separate Session aggregates (BR-127, DeleteEventHandler.cs:37-43), its Sponsor aggregates (DeleteEventHandler.cs:45-52, otherwise the public sponsor strip keeps reading orphaned rows) and its Activity aggregates (DeleteEventHandler.cs:54-61, same reasoning for the public activities page), and hands all four collections to the domain's EventCascadeDeletionDomainService (DeleteEventHandler.cs:64, BR-72/BR-55), because a cross-aggregate cascade is an application-layer decision. The Speaker and Question aggregates use the framework's DeleteEntityHandler<TEntity, TIdentifierType> bound closed in the composition root (MMCA.ADC.Conference.Application/DependencyInjection.cs:78, :84), and Category, Activity and Sponsor get theirs from the bulk AddEntityCrud calls described below.

The richer update handlers ride a third base, MutateEntityPayloadHandlerBase<TCommand, TEntity, TIdentifierType, TResultPayload>, which adds a MutationContext: a small keyed bag that lets MutateAsync stash something the result builder needs. That is how UpdateSessionHandler and UpdateEventHandler return the two-part records UpdateSessionResult and UpdateEventResult, each carrying the DTO plus a non-blocking warning flag. The session variant rejects immutable-field edits with Error.UnprocessableEntity (BR-140, MMCA.ADC.Conference.Application/Sessions/UseCases/Update/UpdateSessionHandler.cs:44-52), loads the parent event once for both the room checks and the BR-86 comparison (:54-63), and sets the "scheduled outside the event's date range" flag under a named key (:26, :98-100, computed at :122-131) that BuildResult reads back (:110-116). The event variant detects a BR-131 time-zone change before the mutation overwrites the stored value, and only pays for the "does this event have sessions" probe when the value actually moves (MMCA.ADC.Conference.Application/Events/UseCases/Update/UpdateEventHandler.cs:43-57). Both stamp the client's concurrency token so a concurrent edit surfaces as a 412 instead of last-write-wins (UpdateSessionHandler.cs:31-35, UpdateEventHandler.cs:30-34, ADR-035).

Both the create and update session paths run the shared room checks through SessionRoomScheduling.ValidateRoomAssignmentAsync (MMCA.ADC.Conference.Application/Sessions/Validation/SessionRoomScheduling.cs:44, called at MMCA.ADC.Conference.Application/Sessions/UseCases/Create/CreateSessionHandler.cs:111-119 and UpdateSessionHandler.cs:66-74). It enforces two rules: the requested room must belong to the session's own event (BR-130, SessionRoomScheduling.cs:59-67), and the requested slot must not double-book the room, probed with BuildOverlapPredicate (SessionRoomScheduling.cs:93), a SQL-translatable half-open interval comparison (s.StartsAt < endsAt && s.EndsAt > startsAt, SessionRoomScheduling.cs:103-106) so back-to-back sessions in one room do not collide, with int.MinValue as an "exclude nothing" sentinel that keeps the predicate a single shape (SessionRoomScheduling.cs:99-101). The class documents the overlap half as a deliberate soft guard (SessionRoomScheduling.cs:16-25): the existence probe and the write that follows are separate statements, so two concurrent organizer writes can both observe a free window; SQL Server has no range-exclusion constraint to express the rule as an index, and the trade-off is accepted because the endpoints are organizer-only and the outcome is repairable. Writing that reasoning down beside the code is [Rubric §34, Architecture Governance & Documentation] in practice.

CreateSessionHandler carries one more piece of orchestration on top of the create base. Session ids are app-assigned (the integer primary key is the Sessionize id), so an organizer create computes the next id in the reserved manual range bounded by SessionInvariants.ManualIdRangeStart/End inside the base's PrepareAsync hook (CreateSessionHandler.cs:79-95), and because two concurrent creates can compute the same id, the handler overrides HandleAsync to retry a bounded three times (CreateSessionHandler.cs:33, :60), each retry in a fresh DI scope because the ambient DbContext still tracks the failed insert (CreateSessionHandler.cs:54-58). An explicitly supplied id (a Sessionize import) is respected as-is and gets a single attempt (CreateSessionHandler.cs:42-43). The layering rule that forbids an EF Core or SQL-client reference here does not force string matching on the exception message: the handler injects the framework port IUniqueConstraintViolationDetector and asks it (CreateSessionHandler.cs:27, used in the catch filter at :60), so the provider-specific knowledge stays in infrastructure. That is [Rubric §29, Resilience & Business Continuity] applied at the write path (a genuinely concurrent case handled in code rather than pushed to the caller) and [Rubric §3, Clean Architecture] holding the line while doing it.

Manual mapping, validation rule fragments, and authorization specifications

Three sibling families recur across every aggregate. DTO mappers (SessionDTOMapper, EventDTOMapper, SpeakerDTOMapper, SponsorDTOMapper, ActivityDTOMapper, RoomDTOMapper, CategoryItemDTOMapper, and the question-answer / category-item link mappers) implement the Common mapper contract and are Mapperly source-generated: the class is [Mapper] and partial, and the mapping method is a partial declaration the generator fills in at compile time (MMCA.ADC.Conference.Application/Categories/DTOs/CategoryItemDTOMapper.cs:11-16). Child collections are delegated to the child's own mapper through [UseMapper] fields rather than re-declared (MMCA.ADC.Conference.Application/Sessions/DTOs/SessionDTOMapper.cs:20-30). This is the deliberate choice of ADR-001 (compile-time mapping over reflection-based AutoMapper), so a renamed property is a build error, not a silent null. Where a mapper needs a rule the generator cannot express it writes the method itself and calls the generated one: SpeakerDTOMapper does exactly that to strip the speaker's email for non-organizers (BR-66, MMCA.ADC.Conference.Application/Speakers/DTOs/SpeakerDTOMapper.cs:30-37), which is [Rubric §11, Security] and [Rubric §30, Compliance, Privacy & Data Governance] enforced at the one boundary every read crosses. [Rubric §9, API & Contract Design] assesses explicit, traceable contracts: the mapping is code you can read and test, not convention magic.

Validation is composed, not inherited. Small generic rule fragments (EventDateRangeRules<T>, EventNameRules<T>, RoomCapacityRules<T>, SessionTitleRules<T>, SpeakerFirstNameRules<T>, SponsorNameRules<T>, ActivityTimeRangeRules<T>, CategoryItemNameRules<T>, and three dozen siblings) each encapsulate one validated concern behind a property selector: the plain string ones subclass the framework's RequiredStringRules<T> and pass the domain's max-length invariant through (MMCA.ADC.Conference.Application/Events/Validation/EventValidationRules.cs:13-18), while the ones with real logic derive from AbstractValidator<T> directly, such as EventTimeZoneRules<T>, which additionally proves the value is a resolvable IANA identifier via TimeZoneInfo.FindSystemTimeZoneById (EventValidationRules.cs:25-48, BR-87). The optional fields compile the selector and wrap a shared fragment in a When(...) guard so an empty value is simply absent rather than invalid: EventOrganizerContactEmailRules<T> wraps EmailRules<T> (EventValidationRules.cs:62-65), and EventSponsorshipPacketUrlRules<T> and EventTicketingUrlRules<T> wrap AbsoluteUrlRules<T> (EventValidationRules.cs:82-85 and :102-105), whose scheme check keeps a rendered link from carrying an executable javascript: or data: target. EventDateRangeRules<T> is the richest, compiling the StartDate selector into a delegate (EventValidationRules.cs:126) and reading it inside a cross-property Must on EndDate (EventValidationRules.cs:127-129); ActivityTimeRangeRules<T> is the same shape one aggregate over (MMCA.ADC.Conference.Application/Activities/Validation/ActivityValidationRules.cs:105-108). Every rule carries a stable error code alongside its message (EventValidationRules.cs:30-32), so clients and tests key off the failure without string-matching prose.

The fragments are assembled twice, not per validator. Each aggregate declares the field set its create and update requests share as an interface (IEventFieldsRequest, ISessionFieldsRequest, ISpeakerFieldsRequest, IActivityFieldsRequest, ISponsorFieldsRequest), and one generic *FieldRules<T> constrained to it includes every fragment once (EventFieldRules<T> at EventValidationRules.cs:139-150, and its ActivityFieldRules<T>, SessionFieldRules<T>, SpeakerFieldRules<T> and SponsorFieldRules<T> siblings). The per-use-case validators then shrink to an Include(...) plus their own delta: EventUpdateRequestValidator is one include and one update-only enum check for the BR-233 moderation default the create request does not carry (MMCA.ADC.Conference.Application/Events/UseCases/Update/EventUpdateRequestValidator.cs:11-18). The pattern mirrors the framework's rule-fragment families in G06, Validation. [Rubric §24, Forms, Validation & UX Safety] and [Rubric §1, SOLID] both apply: fragments compose without an inheritance chain, and a new constraint is a new fragment that touches no existing validator.

Authorization and scoping specifications are the read-side half of the same story, and the module keeps exactly two of them. PublishedEventSpecification filters events to e => e.IsPublished (BR-108, MMCA.ADC.Conference.Application/Events/Specifications/PublishedEventSpecification.cs:14), and PublicSessionStatusSpecification holds the BR-49 status allow-list as a static readonly Expression so the predicate can be composed into other expressions rather than only applied as a specification (MMCA.ADC.Conference.Application/Sessions/Specifications/PublicSessionStatusSpecification.cs:23-27). The allow-list is deliberately positive ("Status is null, or Status is Accepted") rather than a list of exclusions, and it compares against the constant instead of calling SessionStatuses.IsEligible, because a compiled method would not translate to SQL (PublicSessionStatusSpecification.cs:12-19). Both are Specification<TEntity, TIdentifierType> implementations passed into the query services to scope what a caller may read, which keeps the authorization predicate a reusable, testable expression rather than an if buried in a controller. [Rubric §11, Security] assesses authorization that is data-scoped, not just endpoint-gated.

The composition point above them is PublicConferenceVisibility (MMCA.ADC.Conference.Application/Common/PublicConferenceVisibility.cs:28), a static resolver with three public methods and one rule each: published event ids (BR-108, :36-48), visible session ids (the BR-49 allow-list ANDed with the published-event scoping, built through the framework's CrossSourceSpecification helper, :57-82), and visible speaker ids (BR-239: the speakers of at least one eligible session inside the scoped event set, :104-134, over a private helper that re-applies the allow-list inside an already narrowed scope, :141-158). Everything is expressed as scalar id projections rather than navigation joins, so the criteria stay translatable on any engine (ADR-018) and each aggregate keeps its by-id boundary to the others (PublicConferenceVisibility.cs:22-26). A scoped request narrows the rule to one event and only while that event is published, so an unpublished or unknown scope has no public speakers at all rather than erroring (:111-120). The speaker rule's remarks record a real leak that shaped it: the EventSpeaker join is deliberately not a visibility grant, because the Sessionize import writes a row for every speaker in the response, so reading it as one published the whole imported roster and made the filter vacuous (PublicConferenceVisibility.cs:97-103).

Several query handlers build a specification instead of returning data, and they exist because a navigating predicate (s => s.Event.IsPublished) is not translatable once the two entities can live in different data sources (ADR-006, ADR-018). GetPublicSessionFilterHandler uses the same CrossSourceSpecification helper to resolve the published Event ids and return a translatable Session.EventId IN (...) filter, ANDed with the shared status allow-list (MMCA.ADC.Conference.Application/Sessions/UseCases/GetPublicSessionFilter/GetPublicSessionFilterHandler.cs:29-38). GetPublicSponsorFilterHandler, GetPublicActivityFilterHandler and GetPublicRoomFilterHandler do the simplest version of the same move, wrapping the published-event id list in an InlineSpecification<TEntity, TIdentifierType> (MMCA.ADC.Conference.Application/Sponsors/UseCases/GetPublicSponsorFilter/GetPublicSponsorFilterHandler.cs:25-30, MMCA.ADC.Conference.Application/Activities/UseCases/GetPublicActivityFilter/GetPublicActivityFilterHandler.cs:25-30, MMCA.ADC.Conference.Application/Events/UseCases/GetPublicRoomFilter/GetPublicRoomFilterHandler.cs:25-30). GetSessionsBySpeakerFilterHandler and GetSpeakersByEventFilterHandler hand-roll the same id-list shape against the link tables, projecting ids through GetReadRepository(...).GetProjectedAsync and materializing them once so the predicate embeds a stable collection EF can translate to IN (MMCA.ADC.Conference.Application/Sessions/UseCases/GetSessionsBySpeakerFilter/GetSessionsBySpeakerFilterHandler.cs:30-43, MMCA.ADC.Conference.Application/Speakers/UseCases/GetSpeakersByEventFilter/GetSpeakersByEventFilterHandler.cs:28-53, which unions the direct EventSpeaker links with the transitive SessionSpeaker ones). An empty id list correctly matches nothing, which is why the caller must still apply the specification rather than skip it (GetSessionsBySpeakerFilterHandler.cs:15-19).

Query services, navigation populators, and the composition root

Read paths do not get bespoke handlers for the common cases; they go through the framework's generic IEntityQueryService<TEntity, TEntityDTO, TIdentifierType>, which supplies filtering, sorting, paging, and field projection (ADR-034). The one local specialization is SpeakerEntityQueryService, a thin subclass of EntityQueryService<TEntity, TEntityDTO, TIdentifierType> that overrides only the DTO-to-entity property map so API consumers can sort and filter on the computed FullName while the pipeline translates it to (FirstName + " " + LastName) (MMCA.ADC.Conference.Application/Speakers/SpeakerEntityQueryService.cs:28-34). Eager-loading of child graphs is delegated to per-aggregate INavigationPopulator<in TEntity> implementations (EventNavigationPopulator, SessionNavigationPopulator, SpeakerNavigationPopulator, ActivityNavigationPopulator, SponsorNavigationPopulator, ConferenceCategoryNavigationPopulator, plus one per child entity), which encapsulate which navigations to include and how to batch-load cross-source relationships (ADR-002); the childless Question aggregate uses the framework's NullNavigationPopulator<TEntity> because it is never the root of a full graph load (MMCA.ADC.Conference.Application/DependencyInjection.cs:85).

All of this is wired by DependencyInjection, the module's composition root (MMCA.ADC.Conference.Application/DependencyInjection.cs:49, with the registration surface exposed as a C# extension(IServiceCollection) member at DependencyInjection.cs:48-50). It explicitly binds the closed generics Scrutor cannot infer (the cascade-deletion domain service at :55, the AI scoring queue at :61-62, then each aggregate's navigation populator, query service, and, where the module owns one, delete handler at :65-120, plus the two cross-module validation services at :123 and :126), and then calls ScanModuleApplicationServices<ClassReference>() (DependencyInjection.cs:130) to discover the "many small things" (every handler, mapper, validator, applier, and event handler) by convention. AssemblyReference and ClassReference are the marker types that anchor that scan (MMCA.ADC.Conference.Application/AssemblyReference.cs:5 and :11).

The ordering of the last block is load-bearing and the file says so. Three plain-CRUD aggregates get their create, update and delete verbs from one AddEntityCrud call each (Category, Activity, Sponsor, DependencyInjection.cs:140-142), and Speaker gets the derived-command update path because BR-214's CallerIsOrganizer is state the request body must never hold (DependencyInjection.cs:150). Those calls sit after the scan on purpose: they use TryAdd, so the module's own CreateXHandler (already registered by the scan, and the only one of the three verbs that still carries module vocabulary in a log line) keeps the create verb, while the update and delete verbs, which nothing in this assembly registers, come from the framework. The mutation itself still lives on the aggregate, reached through the *UpdateApplier the scan picked up beside the create mapper (ConferenceCategoryUpdateApplier, ActivityUpdateApplier, SponsorUpdateApplier, and the command-aware SpeakerUpdateApplier, which implements IEntityUpdateCommandApplier<TEntity, TUpdateRequest, TIdentifierType, in TCommand> rather than the request-only IEntityUpdateApplier<TEntity, TUpdateRequest, TIdentifierType> at MMCA.ADC.Conference.Application/Speakers/UseCases/Update/SpeakerUpdateApplier.cs:13-14). [Rubric §7, Microservices Readiness] assesses clean, explicit module boundaries: every internal concrete type is reachable only through an interface registered here, which is exactly what lets the Conference module boot as its own service host. [Rubric §33, Developer Experience]: one file is the single place a new aggregate gets registered.

Event-driven reactions: domain and integration handlers

The application layer is also where the module reacts to events. The module keeps exactly one domain event handler, and it is the one with a real side effect. SpeakerDeletedHandler implements IDomainEventHandler<in TDomainEvent> over the entity's single lifecycle event, SpeakerChanged, and switches on its state discriminator, the taxonomy ADR-083 settles: everything but DomainEntityState.Deleted returns immediately (MMCA.ADC.Conference.Application/Speakers/DomainEventHandlers/SpeakerDeletedHandler.cs:29-30). On a delete with a previously linked user it opens its own DI scope (the handler is a singleton), resolves IEventBus, and publishes SpeakerUnlinkedFromUser so Identity can clear User.LinkedSpeakerId (SpeakerDeletedHandler.cs:38-45, BR-70). The LinkedUserId on the Conference side was already cleared inside Delete(), so this is the cross-module half of the cleanup and is deliberately eventually consistent (SpeakerDeletedHandler.cs:10-19).

The write side of the same link works in the other direction and inside the transaction: LinkUserToSpeakerHandler derives from MutateEntityHandlerBase<TCommand, TEntity, TIdentifierType>, enforces the BR-208 one-speaker-per-user guard (MMCA.ADC.Conference.Application/Speakers/UseCases/LinkUser/LinkUserToSpeakerHandler.cs:42-55), and raises SpeakerLinkedToUser on the aggregate before the save, so the outbox row is captured in the same SaveChangesAsync as the link (:57-64, ADR-003).

The integration event handler UserRegisteredHandler is the cross-module boundary in the other direction: when Identity publishes UserRegistered over the broker, Conference auto-links a speaker to that user (BR-207). It does not implement IIntegrationEventHandler<in TIntegrationEvent> directly; it derives from ScopedIntegrationEventHandlerBase<TIntegrationEvent> (MMCA.ADC.Conference.Application/Users/IntegrationEventHandlers/UserRegisteredHandler.cs:45-48), which supplies the per-event DI scope a singleton needs to resolve a scoped IUnitOfWork and the log-and-propagate envelope around the body; the handler overrides HandleScopedAsync (:51-105) and customizes only the failure log line (:126-127). The only auto-link signal is an email match. The handler resolves the address through the Email value object (normalized to lowercase, so the comparison is effectively case-insensitive) and orders the candidates so an unlinked speaker wins and the choice stays deterministic when an address is shared (UserRegisteredHandler.cs:129-157). On a miss it runs a read-only name-match probe that counts unlinked speakers with the same first and last name and logs the count (:166-192): the matched rows are never returned, so no code path can link on a name. Name-based auto-linking was removed for security (bug hunt C5), and the documented consequence is that a legitimate speaker who registers after a name-only Sessionize import (the public feed omits PII, so Email is null) no longer links by itself, with that log line as the trail an organizer follows to link them manually through PUT /Speakers/{id}/link (BR-209, :17-26, :159-165). On a hit the handler links, saves, and publishes SpeakerLinkedToUser back to Identity (:86-104).

Two details of that handler are worth reading closely. Failures are not swallowed: the base logs and lets the exception propagate, and the remarks record the change of mind (:113-125). Swallowing meant one transient database fault lost the auto-link permanently, because the delivery was already acked, so letting the exception through hands the retry decision to the delivery mechanism, which is built for it (the outbox retries then dead-letters, MassTransit redelivers then moves the message to the error queue). Retrying is safe, because the "already linked to a different user" guard (:70-74) makes the second attempt a no-op, and the same guard resolves the rare unique-index race on Speaker.LinkedUserId (:93-97). Publishing flows through the IEventBus abstraction and the outbox (ADR-003), so the application code never references MassTransit. [Rubric §6, CQRS & Event-Driven] and [Rubric §7, Microservices Readiness]: the module collaborates through events and interfaces, never direct cross-module type references.

Two in-process services close the loop with the Engagement module. SessionBookmarkValidationService (MMCA.ADC.Conference.Application/Sessions/SessionBookmarkValidationService.cs:12) and EventLiveValidationService (MMCA.ADC.Conference.Application/Events/EventLiveValidationService.cs:24) implement the Engagement-facing contracts ISessionBookmarkValidationService and IEventLiveValidationService, which Engagement calls via gRPC when the modules run as separate services (ADR-007). The former gates session bookmarking through the domain's SessionInvariants (EnsureNotServiceSession for BR-91, EnsureStatusIsEligible for BR-49, SessionBookmarkValidationService.cs:32-38), so the eligibility rule is the domain's, not a copy, and also answers the "which sessions belong to this event" lookup Engagement needs for event-scoped reads (SessionBookmarkValidationService.cs:42-54). The latter answers four live-layer questions (the event's window at EventLiveValidationService.cs:25, a session's at :48, a sponsor booth's at :104, and which session a room is hosting right now at :143, so a check-in never has to trust a client-supplied session id) and deliberately does not compute the window itself: it delegates to the domain's CurrentEventSelector.GetLiveWindowUtc (EventLiveValidationService.cs:223-230) so the midnight-to-midnight rule and the spring-forward-gap guard stay identical to the ones the home surfaces and the now/next snapshot use. Its session variant adds the assigned speaker ids (BR-236), the plenum flag, and the event's question-moderation default (BR-233, EventLiveValidationService.cs:90-100) after re-applying the BR-91 and BR-49 eligibility checks (:65-73). The traffic also runs the other way: GetSessionBookmarkCountsHandler re-verifies server-side that every requested session really belongs to the speaker before delegating the counting to Engagement's batched IBookmarkCountService, silently dropping ids that are not the speaker's rather than failing the whole batch (MMCA.ADC.Conference.Application/Speakers/UseCases/GetSessionBookmarkCounts/GetSessionBookmarkCountsHandler.cs:40-46), which is [Rubric §11, Security] (never trust the client's id list) and [Rubric §12, Performance & Scalability] (one cross-service round-trip instead of one per session) in a single handler.

Attendee-facing read models: calendar export and Now/Next

A small cluster of queries serves the public schedule surfaces without going through the generic query service, because their output is not a DTO list. ExportEventCalendarHandler and ExportSessionCalendarHandler return a Result<string> holding an .ics document: the event variant loads the event with its rooms, refuses unpublished or unknown events with Error.NotFound (MMCA.ADC.Conference.Application/Sessions/UseCases/ExportCalendar/ExportEventCalendarHandler.cs:25-32), and turns every exportable session into one VEVENT with the room as its location (:43-51), with CalendarExportMapper doing the entity-to-entry shaping and owning the IsExportable eligibility rule, which itself defers the status half to SessionStatuses.IsEligible so no second copy of the allow-list can drift (MMCA.ADC.Conference.Application/Sessions/UseCases/ExportCalendar/CalendarExportMapper.cs:26-28), and the framework's IcsCalendarBuilder assembling the document (ExportEventCalendarHandler.cs:53). The export is role-independent by design: a privileged caller gets the same filtered document (CalendarExportMapper.cs:19-25). The time-zone lookup has no fallback and says why: EventInvariants.EnsureTimeZoneIsValid guards every write path, so an unresolvable stored id is a data defect that must surface rather than quietly degrade to UTC (ExportEventCalendarHandler.cs:39-41, and the same comment on the two sibling handlers at MMCA.ADC.Conference.Application/Sessions/UseCases/ExportCalendar/ExportSessionCalendarHandler.cs:47-49 and MMCA.ADC.Conference.Application/Sessions/UseCases/NowNext/GetNowNextHandler.cs:43-45).

GetNowNextHandler builds the conference-day "happening now plus next up" snapshot for one published event or, when no id is given, the auto-selected current-or-next published event using the domain's CurrentEventSelector rule (GetNowNextHandler.cs:84-95), reusing the same CalendarExportMapper.IsExportable rule and the same DST-aware wall-clock conversion as the calendar export (:47-50, :74-82) and reporting the event's live flag from the same GetLiveWindowUtc window (:68-69). "Now" is every row whose window straddles the current instant, ordered by start then room (:52-56), and "next" is the whole batch sharing the earliest future start, so parallel tracks surface together rather than one arbitrary winner (:58-66). GetNowNextHandler injects TimeProvider rather than reading the clock directly (:22, :29), which is what makes its "now" unit-testable at a fixed instant; the two export handlers instead stamp the .ics DTSTAMP from DateTimeOffset.UtcNow directly (ExportEventCalendarHandler.cs:53, ExportSessionCalendarHandler.cs:51-54), so their timestamp is not injectable. [Rubric §14, Testability].

The Sessionize import: Strategy-pattern orchestration

The single most involved use case is importing a conference agenda from Sessionize.com. Sessionize returns one JSON payload covering five interdependent entity families (categories, rooms, questions, speakers, and sessions, where sessions reference rooms and speakers and speakers reference categories). The HTTP shape is captured by a set of deserialization records (SessionizeResponse, SessionizeSession, SessionizeSpeaker, SessionizeRoom, SessionizeCategory, SessionizeCategoryItem, SessionizeQuestion, SessionizeQuestionAnswer, SessionizeLink) whose [JsonPropertyName] attributes are the only place the provider's wire vocabulary appears (MMCA.ADC.Conference.Application/Events/Sessionize/SessionizeModels.cs:6-22), an anti-corruption boundary so a Sessionize API change never touches a domain entity.

The import is fetched through the ISessionizeService port (implemented by the HTTP client in G19, Conference Infrastructure) and orchestrated by RefreshFromSessionizeHandler (MMCA.ADC.Conference.Application/Events/UseCases/RefreshFromSessionize/RefreshFromSessionizeHandler.cs:20). That handler does orchestration only: load the Event with its rooms and speakers eagerly (:43-48), enforce BR-6 (a Sessionize code must be configured, :56-64) and the BR-63 five-minute throttle (:66-75, measured against an injected TimeProvider), then call the external API inside a try/catch whose filter converts any "no usable data right now" condition into an Error rather than a 500. That filter is worth reading: because the client runs behind the standard resilience pipeline, an unreachable API arrives as a Polly TimeoutRejectedException or BrokenCircuitException as often as an HttpRequestException, and an HTML error page served with a success status arrives as a JsonException or NotSupportedException, so all five share one friendly failure (:83-93, :156-171), with an explicit ThrowIfCancellationRequested() first so caller cancellation is never reported as an upstream outage (:86).

The handler then runs five ISessionizeSyncStrategy implementations in dependency order (CategorySyncStrategy, RoomSyncStrategy, QuestionSyncStrategy, SpeakerSyncStrategy, SessionSyncStrategy, declared at :28-35 and invoked at :123-126), each carrying its work via a shared SessionizeSyncContext (:114-120) and returning a SessionizeSyncResult with a primary and an optional secondary count (ISessionizeSyncStrategy.cs:21-28). An empty response is treated as success, not an error, and still stamps the refresh (:95-111). Each strategy bulk-loads its entity family in one call (no N+1, MMCA.ADC.Conference.Application/Events/UseCases/RefreshFromSessionize/SessionSyncStrategy.cs:21-29), upserts via the domain's Create/Update methods (SessionSyncStrategy.cs:73-115), skips soft-deleted rows (BR-136, SessionSyncStrategy.cs:79-85, warned once at RefreshFromSessionizeHandler.cs:128-131), and accumulates human-readable warnings through SessionizeSyncWarnings instead of aborting on one bad record (SessionSyncStrategy.cs:104-110, plus the BR-86/BR-122 time warnings at :53-71). A final RequestIdentityInsert() (RefreshFromSessionizeHandler.cs:138) lets SQL Server accept Sessionize's own integer IDs before one batched SaveChangesAsync (:139). [Rubric §2, Design Patterns] (Strategy solving a real Open/Closed problem: a new entity family is a new strategy, not an edit to the orchestrator), [Rubric §12, Performance & Scalability] (bulk loads plus a single save round-trip), and [Rubric §17, DevOps & Deployment] (the throttle, the feature gate, and graceful per-entity degradation make a re-import safe to run repeatedly).

Decision support: AI scoring and content analytics

The last cluster is session-selection decision support, analytics that help organizers triage proposals. GetSessionSelectionDashboardHandler is a composite query: it validates the event, then loads the event's non-service sessions with their speakers and category items, the categories, and the referenced speakers, each in one call (MMCA.ADC.Conference.Application/Sessions/UseCases/DecisionSupport/GetSessionSelectionDashboard/GetSessionSelectionDashboardHandler.cs:23-63), and computes summary counts, category distribution, speaker-session overlap, content similarity, and speaker locality into one dashboard DTO. The speaker load deliberately runs with query filters off (:52-62): speaker deletion does not cascade to the SessionSpeaker link (BR-70/BR-71), so filtering here would render a real speaker as "Unknown" instead of the truth, and every downstream consumer re-filters the child collections in memory anyway. The narrower queries (GetCategoryDistributionQuery, GetContentSimilarityQuery, GetSpeakerSessionOverlapQuery) remain dispatchable individually. Content similarity is computed by the internal, pure-static SessionSimilarityCalculator, a weighted sum of two Jaccard indices, category-item overlap at 60% (MMCA.ADC.Conference.Application/Sessions/UseCases/DecisionSupport/GetContentSimilarity/SessionSimilarityCalculator.cs:11) and span-tokenized keyword overlap at 40% (:12, with a FrozenSet stop-word list at :14-34 that includes conference-generic words like "SESSION" and "WORKSHOP", and a three-character minimum token length at :62), combined at :97-105, above a tunable threshold whose default is 0.3 (MMCA.ADC.Conference.Application/Sessions/UseCases/DecisionSupport/GetContentSimilarity/GetContentSimilarityQuery.cs:6), flagging proposals that would compete for the same audience. SpeakerLocalityHelper resolves a speaker's locality tier through the "where are you traveling from" category assignment rather than a Speaker field (MMCA.ADC.Conference.Application/Sessions/UseCases/DecisionSupport/SpeakerLocalityHelper.cs:36-38), keeping a LocalityLookupEntry per item so a speaker carrying items from several yearly imports resolves to the most recent category (SpeakerLocalityHelper.cs:6-15), with the original Sessionize category id 121854 as the fallback when no title matches the heuristic (SpeakerLocalityHelper.cs:27). The two private per-handler StatusBucket enums map SessionStatuses values into display groupings (GetSessionSelectionDashboardHandler.cs:314-319 and MMCA.ADC.Conference.Application/Sessions/UseCases/DecisionSupport/GetCategoryDistribution/GetCategoryDistributionHandler.cs:94).

The flagship is AI scoring, and it is the one use case in this assembly that does not run on the request thread. Scoring an event takes minutes and issues one paid Anthropic call per session, so the API controller does not await it: it calls ISessionScoringQueue.TryEnqueue and turns the returned SessionScoringEnqueueResult into 202 Accepted or a conflict (MMCA.ADC.Conference.Application/Sessions/UseCases/DecisionSupport/ScoreEventSessions/ISessionScoringQueue.cs:4-14, consumed by SessionSelectionController). That bounded-queue-plus-hosted-drain shape is the pattern ADR-052 settles for the whole codebase. SessionScoringQueue is a bounded Channel of capacity 16 (MMCA.ADC.Conference.Application/Sessions/UseCases/DecisionSupport/ScoreEventSessions/SessionScoringQueue.cs:38) with SingleReader set and FullMode = Wait paired with a non-blocking TryWrite (:43-49), so a full queue refuses the new request outright instead of dropping an earlier one, which matters because each run is expensive and the caller needs to know it was not accepted (:26-32). It claims the event id in a ConcurrentDictionary before writing, so a concurrent duplicate loses the TryAdd and is refused rather than silently coalesced (:64-77); the claim is released only by MarkCompleted after the run finishes (:110), so the dedup window covers execution too, not just the wait in the queue. A queued SessionScoringWorkItem carries its attempt number (:21) so the drain worker can schedule a bounded retry through TryRequeue (:93-103) without keeping per-event state of its own, which the type documents as an intentional floor: an in-process, best-effort queue loses the retry if the process dies, and an organizer can always trigger the run again (:9-14). The interface's own remarks record what all of this replaced: a fire-and-forget task started from the controller that nothing tracked, nothing deduplicated, and nothing could cancel at shutdown (ISessionScoringQueue.cs:16-30). The single drain worker lives in infrastructure (SessionScoringProcessor), which is why DependencyInjection registers the concrete queue and the interface as the same singleton instance (DependencyInjection.cs:61-62): two instances would mean producers writing to a queue nobody drains. [Rubric §12, Performance & Scalability] and [Rubric §29, Resilience & Business Continuity].

The run itself is ScoreEventSessionsCommand, handled by ScoreEventSessionsHandler: a full re-score that loads every non-service session for the event (MMCA.ADC.Conference.Application/Sessions/UseCases/DecisionSupport/ScoreEventSessions/ScoreEventSessionsHandler.cs:30-34), batch-loads the speakers into a lookup (:39-51), then scores session by session through IAiScoringService, a port implemented in infrastructure by AnthropicScoringService, which calls the Anthropic Messages API. The replace strategy is the detail worth studying, because the comment records a reversal (:94-103): an earlier version deleted every score on the event up front in one set-based ExecuteDeleteAsync so the dashboard would reset to zero and count up, but that paid for the progress animation with real data, since N sequential paid calls follow and the first one to fail on an expired key or a rate limit left every session it never reached with no score at all. Today the delete is per-session and happens in the same step that writes the replacement (:104-108), so a run that dies partway through has replaced only what it re-scored; the unique filtered index on SessionId makes the delete-then-add pair safe. Each successful score is saved immediately (:107-108) so the UI can still show real-time progress, a per-session save failure only increments a counter and continues (:113-117), and the command fails as a whole only when every session failed (:127-133). The contract is deliberately never-throw: ScoreSessionAsync returns a SessionScoringResult with a Success flag and seven 1.0-10.0 sub-scores (overall, topic relevance, description quality, novelty, actionable takeaways, depth/insight quality, credibility/experience) in all cases (MMCA.ADC.Conference.Application/Sessions/UseCases/DecisionSupport/ScoreEventSessions/IAiScoringService.cs:9, IAiScoringService.cs:40-71), so one bad session never aborts the scoring loop. The input shapes are SessionScoringInput and SpeakerInfo (IAiScoringService.cs:23-37); the result is mapped onto the SessionAiScore aggregate for persistence (ScoreEventSessionsHandler.cs:79-83). Keeping the port here and the HTTP/LLM adapter in infrastructure is textbook [Rubric §3, Clean Architecture] (the application layer depends on an interface, never the SDK) and [Rubric §7, Microservices Readiness] (the AI provider is swappable behind one interface).

Taken together, this assembly is the codebase's most complete picture of how a use case is built here: a slice per feature, generic framework machinery for the repetitive 80% (query, validate, map, persist, populate, and now the create/mutate handler bases themselves), and bespoke handlers reserved for the genuinely complex 20% (the Sessionize import, the attendee-facing read models, and the decision-support analytics), each isolated behind a port or a strategy so it can evolve, be tested, and ultimately be extracted without disturbing the rest.

ActivityTimeRangeRules<T>

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Activities.Validation · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Activities/Validation/ActivityValidationRules.cs:92 · Level 0 · class (sealed)

• What it is: the one fragment in the activity family that validates a pair of properties rather than a single field: both ends of an activity's time range must be present, and the end must be on or after the start.
• Depends on: FluentValidation's AbstractValidator<T> (NuGet, primer §3) and System.Linq.Expressions.Expression<Func<T, ...>> (BCL). No first-party dependency: unlike its siblings in the same file it reads no domain constant and derives from no framework rule.
• Concept, the module-local rule fragment. The fragment idiom itself (a tiny generic AbstractValidator<T> that a real validator folds in with FluentValidation's Include(...)) is taught in group-06 on RequiredStringRules<T> and its siblings. This file is the Conference module's own layer on top, and it has two shapes. Most of the activity fragments inherit a framework rule and hand it a field label plus a domain constant (see ActivityNameRules<T>). This one, the cross-field rule, cannot: a check that compares two properties needs the instance, not just one selected value, so it writes its own chain. The mechanism is worth learning once because every cross-field rule in the codebase uses it: FluentValidation's Must has an overload taking (instance, value), so the fragment compiles the other selector into a delegate at construction time and calls it against the instance inside the predicate. Every rule written by hand here also attaches a stable dotted error code with WithErrorCode(...) next to its human-readable message, so an API client or a test can key off Activity.EndTime.BeforeStart without string-matching English prose. [Rubric §24, Forms, Validation & UX Safety] assesses whether validation is reused rather than copy-pasted across create and update paths and whether failures are machine-addressable: the fragment plus the error code is this module's answer to both. [Rubric §1, SOLID]: each fragment carries exactly one field contract, so changing that contract is a one-line edit in one place.
• Walkthrough: a two-selector constructor with a statement body, ActivityTimeRangeRules(Expression<Func<T, DateTime>> startTimeSelector, Expression<Func<T, DateTime>> endTimeSelector) (ActivityValidationRules.cs:95-97), building three rules:
  • RuleFor(startTimeSelector).NotEmpty(), message "You must enter a Start Time", code Activity.StartTime.Required (:99-100).
  • RuleFor(endTimeSelector).NotEmpty(), message "You must enter an End Time", code Activity.EndTime.Required (:102-103).
  • var startTimeFunc = startTimeSelector.Compile(); (:105) turns the start-time expression into an executable Func<T, DateTime> once, at fragment construction, not per validation call. The third rule then hangs off the end-time selector and uses the two-argument Must((instance, endTime) => endTime >= startTimeFunc(instance)) (:106-107), reporting "End Time must be on or after the Start Time" with code Activity.EndTime.BeforeStart (:108). Attaching the comparison to the end selector is what makes the error surface on the end-time field in the UI.
• Why it's built this way: the class doc (ActivityValidationRules.cs:87-91) says the shape mirrors EventDateRangeRules, so the two schedule-bearing aggregates fail the same way for the same reason. The >= is deliberate: a zero-length activity passes, and the rule bans only an end before its start, which is exactly the comparison the domain guard makes as well (ActivityInvariants.EnsureTimeRangeIsValid, MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Domain/Activities/ActivityInvariants.cs:79-86, code Activity.TimeRange.Invalid). Request path and domain path therefore agree on the rule and differ only in the code they report, which is how a failure tells you which layer rejected the value.
• Caveats / not in source: NotEmpty() on a non-nullable DateTime rejects default(DateTime), so a genuinely unset value is caught, but a caller that posts a real-but-implausible time (for example far outside the event window) is not: no range-versus-event check exists in this fragment. Both ends are event-local wall times, per the domain doc at ActivityInvariants.cs:71-73; nothing here converts or compares zones.
• Where it's used: pulled in once, by ActivityFieldRules<T> (ActivityValidationRules.cs:136), which is what both ActivityCreateRequestValidator and ActivityUpdateRequestValidator include.

AssemblyReference

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/AssemblyReference.cs:5 · Level 0 · class (static)

• What it is: a tiny static class exposing the Conference Application assembly and its short name as two static readonly fields, so any reflection-driven tooling has a strongly-typed handle on this assembly.
• Depends on: System.Reflection (BCL) only.
• Concept, the assembly-anchor type. [Rubric §5, Vertical Slice] assesses whether a module is a self-contained, discoverable unit; a per-assembly anchor is how reflection-based wiring names "everything in the Conference Application layer" without hard-coding a namespace or assembly string. There is a sibling anchor of the same name in every layer of the module (Conference Domain, Infrastructure, API) and in every other ADC module, so a caller can always name the exact assembly it means.
• Walkthrough: two fields, no methods. Assembly = typeof(AssemblyReference).Assembly (AssemblyReference.cs:7) resolves the containing assembly from the type itself; AssemblyName = Assembly.GetName().Name ?? string.Empty (AssemblyReference.cs:8) reads the simple name and falls back to an empty string when the runtime reports null. Both are computed once at type load.
• Why it's built this way: typeof(X).Assembly is refactor-safe (renaming the assembly, moving the file, or restructuring the namespace changes nothing), which is why the codebase prefers an anchor type over Assembly.Load("...") with a literal.
• Where it's used: nothing in MMCA.ADC references this module's Application anchor today. The consumer pattern is visible one layer over: the Conference Infrastructure anchor is what the design-time EF factory feeds to AddConfigurationAssembly (MMCA.ADC/Source/Hosting/MMCA.ADC.Migrations.SqlServer.Conference/DesignTimeSQLServerDbContextFactory.cs:43). The convention scan performed inside DependencyInjection anchors on ClassReference instead, because that framework API is generic over a type argument rather than over an Assembly value. The class is kept for symmetry with the other layers' anchors and for tooling that wants the Assembly object directly.

ClassReference

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/AssemblyReference.cs:11 · Level 0 · class

• What it is: an empty marker class used purely as a typeof anchor for assembly scanning; it declares no members.
• Depends on: nothing.
• Concept, the scan-anchor marker. [Rubric §2, Design Patterns] assesses idiomatic registration wiring. The framework's scanning API is generic over an anchor type, so ScanModuleApplicationServices<ClassReference>() reads as "scan the assembly that contains ClassReference", that is, this Application layer. The class body is empty (AssemblyReference.cs:11); its only job is to be a compile-time-checked stand-in for the assembly.
• Walkthrough: public class ClassReference { } on one line. No fields, no methods, and deliberately neither sealed nor static, because a static class cannot be used as a generic type argument.
• Why it's built this way: a dedicated marker keeps the scan call site refactor-safe and avoids anchoring the scan on a real domain or handler type that might later move to another assembly.
• Where it's used: passed as the type argument to services.ScanModuleApplicationServices<ClassReference>() in DependencyInjection (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/DependencyInjection.cs:133). The generic parameter it satisfies is TAssemblyMarker on ScanModuleApplicationServices, declared in MMCA.Common (MMCA.Common/Source/Core/MMCA.Common.Application/DependencyInjection.cs:163-165) with a where TAssemblyMarker : class constraint, and its body simply forwards typeof(TAssemblyMarker).Assembly to the Assembly-typed overload (:179).

GetPublicActivityFilterQuery

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Activities.UseCases.GetPublicActivityFilter · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Activities/UseCases/GetPublicActivityFilter/GetPublicActivityFilterQuery.cs:13 · Level 0 · record (sealed)

• What it is: a parameterless query record asking one question: "which activities may an anonymous or non-privileged caller see?". It carries no data at all, and the answer it triggers is a specification, not a page of rows.
• Depends on: nothing. public sealed record GetPublicActivityFilterQuery(); is the entire type, a positional record with an empty parameter list.
• Concept, the specification-returning query. Most CQRS queries return data. This family returns a filter: a Specification<TEntity, TIdentifierType> the caller then hands to the generic read pipeline, which ANDs it with whatever paging, sorting and field selection the request already asked for. [Rubric §11, Security] assesses whether authorization is enforced at the data boundary rather than trusted to the UI: expressing "public visibility" as a server-built specification means a non-privileged caller's query is narrowed before it reaches the database, no matter which endpoint or filter string they sent. [Rubric §6, CQRS & Event-Driven]: the visibility rule is a first-class query use case with its own handler, so it is unit-testable and reusable instead of being an if buried in a controller. The empty record is the CQRS convention taken to its logical end, the query has no inputs because the answer depends only on server state (which events are published) and never on the caller's arguments.
• Walkthrough: no members. The teaching is in the two doc comments. The summary (GetPublicActivityFilterQuery.cs:3-7) states the business rule: an activity is publicly visible when the event it belongs to is published (BR-108), so an event still being assembled does not leak its social programme before announcement. The remarks (:8-12) state the shape choice: Activity carries a real EventId column, so the rule resolves to a published-event id list and comes back as an Activity.EventId IN (...) criteria; no navigation join is involved, so the criteria stays engine-portable and Activity keeps its by-id boundary to Event.
• Why it's built this way: keeping the criteria to scalar id comparisons rather than a navigation join is the polyglot-persistence safeguard of ADR-018; a filter written this way translates on any supported engine, not just SQL Server. It also preserves the DDD rule that one aggregate references another by id (ADR-006 draws the same boundary at the storage level).
• Where it's used: constructed by ActivitiesController inside its GetReadSpecificationAsync override (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.API/Controllers/Activities/ActivitiesController.cs:75) and handled by GetPublicActivityFilterHandler. It is one of the public-filter query family in this module, alongside GetPublicSessionFilterQuery, GetPublicSpeakerFilterQuery, GetPublicSponsorFilterQuery and the rest.

IActivityFieldsRequest

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Activities.Validation · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Activities/Validation/IActivityFieldsRequest.cs:12 · Level 0 · interface

• What it is: the read-only shape of the eight activity fields that the create request and the update request validate identically. Both request records implement it, and it is what lets the shared rule list be declared once.
• Depends on: nothing first-party, nothing external. Eight get-only properties over string, string?, DateTime and int.
• Concept, the shared-field contract behind a validator. [Rubric §15, Best Practices & Code Quality] assesses whether a constraint lives in exactly one place; [Rubric §24, Forms, Validation & UX Safety] assesses whether create and update paths can drift apart. Before a contract like this exists, the usual shape is two validators that each Include the same seven fragments, which is seven chances for the two paths to diverge on the next field added. Declaring the fields as an interface lets a single generic validator (ActivityFieldRules<T>) be written over where T : IActivityFieldsRequest, so each concrete validator keeps only its own per-operation delta. The interface is get-only on purpose: nothing validates through it, it is only read, so an implementing record can keep init-only setters and stay immutable.
• Walkthrough: Name (IActivityFieldsRequest.cs:15, non-nullable, the one required string), Description (:18), StartTime (:21) and EndTime (:24) as event-local wall times, VenueName (:27, where empty means the main conference venue), VenueAddress (:30), VenueUrl (:33), and SortOrder (:36, the tie-breaker between activities starting at the same time). The nullability of each property is load-bearing: it is what decides at compile time whether a required or an optional fragment can be bound to it.
• Why it's built this way: the remarks (IActivityFieldsRequest.cs:8-11) record the one field deliberately left off the interface. The owning event is carried and validated only by the create request, because moving an activity between events is a create plus a delete, so EventId is a create-only delta rather than a shared field. That single omission is what keeps ActivityEventIdRules<T> out of the shared rule set.
• Where it's used: implemented by ActivityCreateRequest (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Activities/UseCases/Create/ActivityCreateRequest.cs:11, alongside ICreateRequest and ICacheInvalidating) and by ActivityUpdateRequest (.../Activities/UseCases/Update/ActivityUpdateRequest.cs:10, where it is the only interface the record implements). Consumed as the generic constraint of ActivityFieldRules<T> (ActivityValidationRules.cs:131).

ActivityEventIdRules<T>

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Activities.Validation · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Activities/Validation/ActivityValidationRules.cs:80 · Level 1 · class (sealed)

• What it is: a reusable rule fragment that enforces "an activity must name the event it belongs to", applied to whichever EventIdentifierType property a caller points it at.
• Depends on: RequiredIdRules<T, TId> (its base class, MMCA.Common/Source/Core/MMCA.Common.Application/Validation/CommonValidationRules.cs:142-148) and System.Linq.Expressions (BCL). The EventIdentifierType in the selector signature (ActivityValidationRules.cs:83) is the module's identifier alias, declared once as a global using in the Shared project and linked solution-wide, which is why no import for it appears in this file.
• Concept: the module-local rule fragment taught on ActivityTimeRangeRules<T>, here in its inheriting form: the fragment writes no RuleFor chain of its own and instead binds a framework rule to a module-specific label and error code. [Rubric §1, SOLID]: one field contract per fragment, so changing it is a one-line edit in one place.
• Walkthrough: one expression-bodied constructor, ActivityEventIdRules(Expression<Func<T, EventIdentifierType>> selector) (ActivityValidationRules.cs:83), whose whole body is the base call : base(selector, "an Event for the Activity", "Activity.EventId.Required") (:84). The base contributes RuleFor(selector).NotEmpty() with the message "You must specify {fieldName}" and the supplied error code (CommonValidationRules.cs:146-147), so the label reads as a full phrase with its own article: "You must specify an Event for the Activity". Because EventIdentifierType aliases int, NotEmpty() here rejects 0, the default of an unset id, rather than a null. The base's remarks (CommonValidationRules.cs:133-139) note that the same check covers a Guid key by rejecting Guid.Empty.
• Why it's built this way: the XML doc above the class (ActivityValidationRules.cs:75-79) states the rule's reason in domain terms: activities are scheduled per event, so an unscoped activity has nowhere to appear. Encoding that as a request-level rule means the caller gets a field-addressed validation failure before any handler or aggregate is touched. Passing the error code explicitly is what makes the failure machine-addressable: the framework's WithOptionalErrorCode helper (CommonValidationRules.cs:30-32) attaches a code only when one is supplied, so a fragment that omits it inherits the base message and no code.
• Where it's used: included by ActivityCreateRequestValidator (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Activities/UseCases/Create/ActivityCreateRequestValidator.cs:15) and by that validator only, as the comment beside the call says (:13-14). ActivityUpdateRequestValidator does not include it, because ActivityUpdateRequest carries no EventId at all: its doc comment (.../Activities/UseCases/Update/ActivityUpdateRequest.cs:6-9) records the choice, moving an activity between events is a create plus a delete, so a mistyped id cannot silently relocate a published social event.

ActivitySortOrderRules<T>

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Activities.Validation · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Activities/Validation/ActivityValidationRules.cs:116 · Level 1 · class (sealed)

• What it is: a reusable rule fragment enforcing that an activity's display sort order is non-negative.
• Depends on: NonNegativeIntRules<T> (its base class, MMCA.Common/Source/Core/MMCA.Common.Application/Validation/CommonValidationRules.cs:122-127), System.Linq.Expressions (BCL). No domain constant.
• Concept: the inheriting form of the module-local rule fragment, as on ActivityEventIdRules<T>. [Rubric §15, Best Practices & Code Quality] assesses whether a constraint lives in one place; a single fragment shared by the create and update paths, itself delegating to one framework rule, is that.
• Walkthrough: one expression-bodied constructor, ActivitySortOrderRules(Expression<Func<T, int>> selector) (ActivityValidationRules.cs:119), body : base(selector, "Sort Order", "Activity.SortOrder.Negative") (:120). The base contributes GreaterThanOrEqualTo(0) with the message "Sort Order must be greater than or equal to 0" (CommonValidationRules.cs:125-126) and attaches the supplied code.
• Why it's built this way: the base chosen is the non-negative one, not PositiveIntRules<T> (CommonValidationRules.cs:100), because zero is a legitimate "first in the list" position. The choice of base class is the business rule here, which is why the class doc (ActivityValidationRules.cs:112-115) says only "non-negative value" and nothing else.
• Where it's used: pulled in once, by ActivityFieldRules<T> (ActivityValidationRules.cs:137), so both the create and the update path get it without either validator naming it.

ActivityDescriptionRules<T>

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Activities.Validation · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Activities/Validation/ActivityValidationRules.cs:25 · Level 7 · class (sealed)

• What it is: a length-only rule fragment for the optional activity description.
• Depends on: OptionalStringRules<T> (its base class, MMCA.Common/Source/Core/MMCA.Common.Application/Validation/CommonValidationRules.cs:53-58), ActivityInvariants (its DescriptionMaxLength constant), System.Linq.Expressions (BCL).
• Concept: the module-local rule fragment (ActivityTimeRangeRules<T>) in its inheriting form. The four optional string rules in this file and ActivityNameRules<T> write no RuleFor chain at all: they subclass a framework fragment and pass it a field label plus the domain's max-length constant. That is the module's whole contribution here, binding a generic rule to a domain invariant. [Rubric §15, Best Practices & Code Quality].
• Walkthrough: one constructor, ActivityDescriptionRules(Expression<Func<T, string?>> selector) (ActivityValidationRules.cs:28), whose body is only a base call: : base(selector, "Activity Description", ActivityInvariants.DescriptionMaxLength) (:29). The base contributes MaximumLength(maxLength) and nothing else (CommonValidationRules.cs:56-57), so null and empty are both accepted. DescriptionMaxLength is 2000, declared on ActivityDTO (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Shared/Activities/ActivityDTO.cs:21) and re-exported as a const by the domain (.../MMCA.ADC.Conference.Domain/Activities/ActivityInvariants.cs:19).
• Why it's built this way: the length is declared once on the DTO, which the Blazor pages bind their input caps to, and read from there by the domain invariants, the EF configuration and this validator (ActivityInvariants.cs:7-12 states exactly that chain), so a schema change cannot leave a stale validator behind.
• Caveats: the inherited fragments pass no error code, so their failures carry a message but no stable code (WithOptionalErrorCode is a no-op when the code is null, CommonValidationRules.cs:30-32). And unlike the name and venue fields, which have domain-side guards emitting coded errors (ActivityInvariants.cs:36, :48, :58, :68), the description has only the constant at ActivityInvariants.cs:19 and no Ensure... guard beside it, so this fragment is the enforcement point on the request path.
• Where it's used: pulled in by ActivityFieldRules<T> (ActivityValidationRules.cs:138), bound to IActivityFieldsRequest.Description.

ActivityNameRules<T>

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Activities.Validation · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Activities/Validation/ActivityValidationRules.cs:13 · Level 7 · class (sealed)

• What it is: the required-string rule fragment for an activity's display name: non-empty and within the domain's maximum length.
• Depends on: RequiredStringRules<T> (its base class, MMCA.Common/Source/Core/MMCA.Common.Application/Validation/CommonValidationRules.cs:41-47), ActivityInvariants (NameMaxLength), System.Linq.Expressions (BCL).
• Concept: the inheriting form of the module-local rule fragment, as on ActivityDescriptionRules<T>. This one subclasses the required base rather than the optional one, which is the only structural difference between the two. [Rubric §1, SOLID], [Rubric §24, Forms, Validation & UX Safety].
• Walkthrough: one constructor, ActivityNameRules(Expression<Func<T, string>> selector) (ActivityValidationRules.cs:16), body : base(selector, "Activity Name", ActivityInvariants.NameMaxLength) (:17). Note the non-nullable string selector, versus the string? of the optional siblings: the compiler enforces at the call site that only a required property can be passed here. The base contributes NotEmpty() plus MaximumLength(...) (CommonValidationRules.cs:44-46), with both messages built from the "Activity Name" label and the max-length message formatted through string.Create(CultureInfo.InvariantCulture, ...), which is what keeps the analyzers-as-errors build satisfied about culture-sensitive formatting. The ceiling is 200 (.../MMCA.ADC.Conference.Shared/Activities/ActivityDTO.cs:18, re-exported at ActivityInvariants.cs:16).
• Why it's built this way: the same value guards the request path here and the aggregate path in ActivityInvariants.EnsureNameIsValid (ActivityInvariants.cs:36-39), which emits the coded errors Activity.Name.Empty and Activity.Name.TooLong. Two layers, one constant, two distinguishable failures.
• Where it's used: pulled in by ActivityFieldRules<T> (ActivityValidationRules.cs:135), bound to IActivityFieldsRequest.Name.

ActivityVenueAddressRules<T>

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Activities.Validation · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Activities/Validation/ActivityValidationRules.cs:49 · Level 7 · class (sealed)

• What it is: a length-only rule fragment for the optional street address of an activity's venue.
• Depends on: OptionalStringRules<T>, ActivityInvariants (VenueAddressMaxLength), System.Linq.Expressions (BCL).
• Concept: the inheriting rule fragment taught on ActivityDescriptionRules<T>. [Rubric §15, Best Practices & Code Quality].
• Walkthrough: one constructor (ActivityValidationRules.cs:52) delegating to : base(selector, "Venue Address", ActivityInvariants.VenueAddressMaxLength) (:53). The ceiling is 500 (.../MMCA.ADC.Conference.Shared/Activities/ActivityDTO.cs:27, re-exported at ActivityInvariants.cs:25), the tightest of the four optional activity strings, and the domain doc records that it deliberately matches the event venue address (ActivityInvariants.cs:24). The domain-side guard is EnsureVenueAddressIsValid (ActivityInvariants.cs:58).
• Where it's used: pulled in by ActivityFieldRules<T> (ActivityValidationRules.cs:140), bound to IActivityFieldsRequest.VenueAddress.

ActivityVenueNameRules<T>

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Activities.Validation · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Activities/Validation/ActivityValidationRules.cs:37 · Level 7 · class (sealed)

• What it is: a length-only rule fragment for the optional name of the venue an activity happens at.
• Depends on: OptionalStringRules<T>, ActivityInvariants (VenueNameMaxLength), System.Linq.Expressions (BCL).
• Concept: the inheriting rule fragment taught on ActivityDescriptionRules<T>.
• Walkthrough: one constructor (ActivityValidationRules.cs:40) delegating to : base(selector, "Venue Name", ActivityInvariants.VenueNameMaxLength) (:41), ceiling 200 (.../MMCA.ADC.Conference.Shared/Activities/ActivityDTO.cs:24, re-exported at ActivityInvariants.cs:22). The class doc (ActivityValidationRules.cs:32-36) records the semantics the emptiness carries: an empty venue name means the main conference venue, which is precisely why this rule is the optional base and not the required one. Absence is meaningful data here, not a missing field.
• Where it's used: pulled in by ActivityFieldRules<T> (ActivityValidationRules.cs:139), bound to IActivityFieldsRequest.VenueName.

ActivityVenueUrlRules<T>

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Activities.Validation · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Activities/Validation/ActivityValidationRules.cs:63 · Level 7 · class (sealed)

• What it is: the rule fragment for the optional external venue website URL: a length bound plus an absolute http/https scheme check, applied only when a value is present.
• Depends on: AbsoluteUrlRules<T> (composed, not inherited, MMCA.Common/Source/Core/MMCA.Common.Application/Validation/CommonValidationRules.cs:85-94), FluentValidation's AbstractValidator<T>, ActivityInvariants (VenueUrlMaxLength), System.Linq.Expressions (BCL).
• Concept, conditional composition inside a fragment. This is the one activity fragment that is neither a plain subclass nor a hand-written chain: it derives from AbstractValidator<T> and folds a framework fragment in under a When(...) guard. [Rubric §26, Front-End Security] and [Rubric §11, Security] both assess whether untrusted input that will later be rendered as a link is constrained at the boundary rather than at the point of rendering. The class doc (ActivityValidationRules.cs:56-62) names the exposure directly: the value cannot become an executable javascript: or data: link when the public activity page renders it. Doing the scheme check here, at the request boundary, means no consumer has to remember it.
• Walkthrough: one constructor, ActivityVenueUrlRules(Expression<Func<T, string?>> selector) (ActivityValidationRules.cs:66), with a two-statement body.
  • var accessor = selector.Compile(); (:68) turns the selector into an executable delegate once, at construction, the same technique ActivityTimeRangeRules<T> uses for its cross-field comparison.
  • When(x => !string.IsNullOrWhiteSpace(accessor(x)), () => Include(new AbsoluteUrlRules<T>(selector, "Venue URL", ActivityInvariants.VenueUrlMaxLength))); (:70-71). The When predicate is what makes an empty value pass outright, and the included framework fragment supplies both checks: MaximumLength(2000) and Must(BeAnAbsoluteHttpUrl) with the message "Venue URL must be an absolute http or https URL" (CommonValidationRules.cs:88-90). The scheme predicate delegates to CommonInvariants.EnsureUrlIsWellFormed (CommonValidationRules.cs:92-93), which passes a null or empty value and otherwise requires Uri.TryCreate(url, UriKind.Absolute, ...) to succeed with a scheme of exactly http or https (MMCA.Common/Source/Core/MMCA.Common.Domain/Invariants/CommonInvariants.cs:293-297, :436-439). The ceiling is 2000 (.../MMCA.ADC.Conference.Shared/Activities/ActivityDTO.cs:30, re-exported at ActivityInvariants.cs:28).
• Why it's built this way: routing the scheme check through the same invariant the domain would call means the validator and the domain answer identically instead of drifting into two definitions of "a usable URL" (CommonValidationRules.cs:77-83 states that intent). A relative path, a bare host, and a javascript: payload all fail the same rule. Keeping the value a plain string rather than a Uri is also deliberate: the framework suppresses CA1054 on the invariant with the note that the point is to validate an untrusted string before anything turns it into a Uri (CommonInvariants.cs:289-292).
• Caveats: the module's own domain guard for this field, ActivityInvariants.EnsureVenueUrlIsValid (.../MMCA.ADC.Conference.Domain/Activities/ActivityInvariants.cs:68-69), is still length-only: it calls EnsureOptionalStringMaxLength and emits Activity.VenueUrl.TooLong, with no scheme check. So the request path is stricter than the aggregate path for this one field, and a value written by a code path that bypasses the request validator would not be scheme-checked. Neither the framework fragment nor this one passes an error code, so a scheme failure carries a message but no stable dotted code.
• Where it's used: pulled in by ActivityFieldRules<T> (ActivityValidationRules.cs:141), bound to IActivityFieldsRequest.VenueUrl.

ActivityFieldRules<T>

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Activities.Validation · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Activities/Validation/ActivityValidationRules.cs:129 · Level 8 · class (sealed)

• What it is: the single fragment that composes all seven shared activity field rules, declared once over IActivityFieldsRequest. It is the only thing the update validator needs, and all but one line of what the create validator needs.
• Depends on: IActivityFieldsRequest (its generic constraint, ActivityValidationRules.cs:131), the seven sibling fragments in the same file (ActivityNameRules<T>, ActivityTimeRangeRules<T>, ActivitySortOrderRules<T>, ActivityDescriptionRules<T>, ActivityVenueNameRules<T>, ActivityVenueAddressRules<T>, ActivityVenueUrlRules<T>), and FluentValidation's AbstractValidator<T>.
• Concept, the composite fragment. The individual fragments answer "how is one field validated". This type answers "what is the field set", and the constraint where T : IActivityFieldsRequest (:131) is what makes the property selectors compile without knowing the concrete request type: p => p.Name binds against the interface, and the closed generic resolves to whichever record the validator supplies. [Rubric §1, SOLID] (open for extension: a new shared field is one interface property plus one Include here, and both request validators pick it up with no edit) and [Rubric §24, Forms, Validation & UX Safety] (the create and update paths cannot drift apart, because there is exactly one list) both land squarely on this type. [Rubric §14, Testability]: because the composite is generic and stateless, a test can instantiate it over either request type, or over a purpose-built stub implementing the interface.
• Walkthrough: a parameterless constructor (ActivityValidationRules.cs:133) with seven Include calls, in the order name, time range, sort order, description, venue name, venue address, venue URL (:135-141). Each one constructs the sibling fragment closed over T and hands it the matching interface property. FluentValidation's Include merges the target validator's rules into this one rather than nesting them, so the failures surface with their own property paths and a caller sees one flat result.
• Why it's built this way: the class doc (ActivityValidationRules.cs:123-128) states the contract: these are the rules the create and the update request share, declared once, with each concrete validator including this and adding only the rules its own operation needs. Today there is exactly one such delta, the create-only ActivityEventIdRules<T>.
• Where it's used: included by ActivityCreateRequestValidator (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Activities/UseCases/Create/ActivityCreateRequestValidator.cs:11, followed by the create-only event-id fragment at :15) and by ActivityUpdateRequestValidator, whose entire body is one expression-bodied Include of this fragment (.../Activities/UseCases/Update/ActivityUpdateRequestValidator.cs:10). Both validators are registered by the convention scan in DependencyInjection (DependencyInjection.cs:133) and reached through the framework's command-to-request validator bridge, which the AddEntityCrud call for Activity completes (DependencyInjection.cs:144).

DependencyInjection

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/DependencyInjection.cs:49 · Level 11 · class (static, extension block)

• What it is: the Conference module's application-layer composition root: a static class exposing AddModuleConferenceApplication(ApplicationSettings), which registers every application service this module needs into the DI container.
• Depends on: ApplicationSettings; the Conference domain aggregates and children (Event, Session, Speaker, Category, CategoryItem, Question, Activity, Sponsor, Room, EventSpeaker, EventQuestionAnswer, SessionSpeaker, SessionCategoryItem, SessionQuestionAnswer, SpeakerCategoryItem, SpeakerQuestionAnswer); the framework generics EntityQueryService<TEntity, TEntityDTO, TIdentifierType>, IEntityQueryService<TEntity, TEntityDTO, TIdentifierType>, INavigationPopulator<in TEntity>, NullNavigationPopulator<TEntity>, DeleteEntityCommand<TEntity, TIdentifierType> and DeleteEntityHandler<TEntity, TIdentifierType>; the cross-module ports ISessionBookmarkValidationService and IEventLiveValidationService; the create/update request records the CRUD registrations close over (ConferenceCategoryCreateRequest, ConferenceCategoryUpdateRequest, ActivityCreateRequest, ActivityUpdateRequest, SponsorCreateRequest, SponsorUpdateRequest, SpeakerUpdateRequest) plus UpdateSpeakerCommand; ClassReference; and Microsoft.Extensions.DependencyInjection with its Extensions namespace (the TryAdd* helpers).
• Concept, the module composition root written as an extension(IServiceCollection) block. [Rubric §5, Vertical Slice] assesses whether each module wires its own slice rather than a central registry knowing about every type; [Rubric §2, Design Patterns] assesses idiomatic registration. The registration method lives inside a C# extension(IServiceCollection services) block (DependencyInjection.cs:51), so callers write services.AddModuleConferenceApplication(settings): the same extension(T) member style used for DI across the codebase, explained once in the primer. The class comment (DependencyInjection.cs:44-48) names the deliberate split this file embodies: explicit registrations for the generic per-entity services (which cannot be discovered by convention, because the closed generic has to be spelled out) and Scrutor assembly scanning for everything hand-written (handlers, mappers, validators), so adding a use case needs no edit here.
• Walkthrough (in body order):
  • _ = applicationSettings (DependencyInjection.cs:55): the settings object is part of the module registration contract but this module does not branch on it today; the discard plus the inline comment "Reserved for future use (e.g., profiler decorators)" is what keeps the unused-parameter analyzer quiet without dropping the parameter from the signature.
  • Domain service (:55): IEventCascadeDeletionDomainService to EventCascadeDeletionDomainService as a singleton. It is stateless, which is why singleton is safe.
  • Session scoring queue (:57-62): SessionScoringQueue is registered concretely (:61) and behind ISessionScoringQueue, with the interface registration written as a factory that resolves the concrete singleton (sp => sp.GetRequiredService<SessionScoringQueue>(), :62) rather than as a second TryAddSingleton<ISessionScoringQueue, SessionScoringQueue>(). The comment above it (:57-60) states why: long-running AI scoring runs off the request path, the hosted drain in Infrastructure needs the reader side and the completion callback, and both registrations must resolve to the ONE instance, or producers would write to a queue nobody drains. This is the classic two-registrations-one-instance trap, and the factory form is the fix.
  • Aggregate roots with custom navigation populators (:64-79): Event (:65-67), Session (:69-71), Speaker (:73-75) and Category (:77-79) each get three scoped registrations, an INavigationPopulator<T> (their bespoke populators EventNavigationPopulator, SessionNavigationPopulator, SpeakerNavigationPopulator, ConferenceCategoryNavigationPopulator), an IEntityQueryService<T, TDTO, TId>, and a delete-command handler. Four of the twelve lines deviate from the generic default, and the deviations are the interesting part: Event binds its delete to the bespoke DeleteEventHandler (:67) because deleting an event has to cascade, Session binds its delete to DeleteSessionHandler (:71), Speaker binds its query service to SpeakerEntityQueryService (:74), and Category binds its delete to DeleteConferenceCategoryHandler (:79). Everything else uses the framework generics unchanged.
  • Aggregate roots with no navigation properties at all (:81-84): Question is the only member of this bucket, and it is the only entity in the whole file registered with NullNavigationPopulator<Question> (:82), the do-nothing populator that satisfies the contract when there is nothing to eager-load, plus the generic EntityQueryService and DeleteEntityHandler.
  • Aggregate roots whose only navigation is the parent Event FK reference (:86-91): Activity (:87-88) and Sponsor (:90-91) each get a bespoke populator (ActivityNavigationPopulator, SponsorNavigationPopulator) that resolves just that back-reference, plus the generic query service. Neither gets a delete handler here: both take theirs from the AddEntityCrud calls further down.
  • Child entities (:93-120): Room, CategoryItem, EventSpeaker, EventQuestionAnswer, SessionSpeaker, SessionCategoryItem, SessionQuestionAnswer and SpeakerCategoryItem each get their own FK populator (RoomNavigationPopulator, CategoryItemNavigationPopulator, EventSpeakerNavigationPopulator, EventQuestionAnswerNavigationPopulator, SessionSpeakerNavigationPopulator, SessionCategoryItemNavigationPopulator, SessionQuestionAnswerNavigationPopulator, SpeakerCategoryItemNavigationPopulator) plus the base EntityQueryService, and deliberately no delete handler: children are removed through their aggregate root, never addressed directly by a delete command. SpeakerQuestionAnswer is the one asymmetry, it gets SpeakerQuestionAnswerNavigationPopulator (:120) but no query service, and the comment above it (:118-119) says so outright: it has no query service today, and registering the populator future-proofs the one that would be added alongside it.
  • Cross-module ports (:122-126): ISessionBookmarkValidationService to SessionBookmarkValidationService (:123) and IEventLiveValidationService to EventLiveValidationService (:126), the in-process interfaces the Engagement module consumes (the file's comments name Engagement and its live layer as the consumers).
  • Convention scan (:130): services.ScanModuleApplicationServices<ClassReference>() sweeps this assembly for, per the comment on :128-129, domain event handlers, DTO/request mappers, command/query handlers, and validators. The framework method behind it (MMCA.Common/Source/Core/MMCA.Common.Application/DependencyInjection.cs:163-165, forwarding to the Assembly overload at :179) first calls ThrowIfPipelineSealed (:182), which fails loudly if AddApplicationDecorators() already ran on this collection, because handlers registered after that point would never be wrapped by the decorator pipeline. It then runs a series of Scrutor services.Scan(...) passes: singleton lifetimes for domain and integration event handlers (:185-196), scoped for mappers and the rest.
  • Generic write side for the plain-CRUD aggregates (:132-142): one AddEntityCrud<...>() call each for Category (:140), Activity (:141) and Sponsor (:142), closed over the aggregate, its DTO, its identifier type, and its create and update request records. The framework method (MMCA.Common/Source/Core/MMCA.Common.Application/DependencyInjection.cs:331-356) registers a generic create handler, a generic update handler and a generic delete handler, all with TryAdd, and then bridges the update command to its request validator with AddCommandRequestValidator (:349-351), which is the call that lets ActivityFieldRules<T> run for an update command the scan never sees. The long comment above the calls (:132-139) explains the placement: these run after the scan on purpose, so the module's own CreateXHandler (already registered, and the only one of the three that still carries module vocabulary in a log line) keeps the create verb, while the update and delete verbs, which nothing in this assembly registers, come from the framework.
  • Derived-command update for Speaker (:144-150): AddEntityUpdate<UpdateSpeakerCommand, Speaker, SpeakerDTO, SpeakerIdentifierType, SpeakerUpdateRequest>() (:150). The comment (:144-149) gives the reason Speaker cannot use the plain CRUD call: its update carries one piece of state the request body must never hold (BR-214's CallerIsOrganizer), so it rides the derived-command path, UpdateSpeakerCommand plus the command-aware SpeakerUpdateApplier the scan picked up. The framework method (.../MMCA.Common.Application/DependencyInjection.cs:442-457) TryAdds the generic command handler and registers the validator bridge, so the module's own UpdateSpeakerHandler keeps the handler slot and the bridge still completes.
  • The method then returns services (:152) for fluent chaining.
• Why it's built this way: every registration uses TryAdd* rather than Add*, so a host (or a test) can register its own implementation first and this method will not clobber it or produce a duplicate registration; the same TryAdd semantics are what let the CRUD and update helpers sit after the scan and fill only the gaps it left. Splitting explicit generics from convention scanning keeps a file that wires roughly twenty entities inside 110 lines of body while still registering the module's dozens of hand-written handlers. Registering the cross-module validation services here as ordinary in-process interfaces is exactly what lets the same module code run co-located or split behind gRPC without a rewrite (ADR-007, ADR-008); the per-entity INavigationPopulator registrations are the populator pattern of ADR-002 being bound one entity at a time.
• Where it's used: called by the Conference module's API-layer registration (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.API/DependencyInjection.cs:25), which is itself invoked through the module's IModule implementation during host startup; modules are discovered and registered in topological order by the ModuleLoader.
• Caveats / not in source: applicationSettings is accepted and immediately discarded; the "profiler decorators" the comment reserves it for do not exist in this layer today. ISessionizeService is absent from this file on purpose: the Application layer owns that port, but its typed-client registration lives in Conference Infrastructure. The ordering constraint the two ThrowIfPipelineSealed guards enforce (this method must run before AddApplicationDecorators()) is checked at registration time, not expressed in the type system, so a host that calls them in the wrong order learns it from an exception rather than from the compiler.

GetPublicActivityFilterHandler

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Activities.UseCases.GetPublicActivityFilter · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Activities/UseCases/GetPublicActivityFilter/GetPublicActivityFilterHandler.cs:16 · Level 11 · class (sealed)

• What it is: the query handler that answers GetPublicActivityFilterQuery. It resolves the ids of the published events and returns an Activity.EventId IN (...) specification the read pipeline can AND into any activity query.
• Depends on: IUnitOfWork (constructor-injected, GetPublicActivityFilterHandler.cs:17), PublicConferenceVisibility, Specification<TEntity, TIdentifierType> and InlineSpecification<TEntity, TIdentifierType>, IQueryHandler<in TQuery, TResult>, Result, and the Activity aggregate it filters.
• Concept, the handler that returns a specification instead of rows. [Rubric §6, CQRS & Event-Driven] assesses whether read intent is modelled as first-class, individually testable use cases; [Rubric §11, Security] assesses whether the visibility rule is applied server-side at the data boundary. Combining the two produces the shape here: the handler's TResult is not a DTO or a page but Result<Specification<Activity, ActivityIdentifierType>> (:18). The caller receives a composable predicate and hands it to the generic entity-query layer, which applies it before paging and sorting, so the rule cannot be defeated by a crafted query string. [Rubric §12, Performance & Scalability] is served by the same choice: the filter arrives as one translated IN clause on a column, not as an in-memory post-filter over a full result set.
• Walkthrough: a primary-constructor class taking IUnitOfWork unitOfWork (:16-17), with one method.
  • HandleAsync(GetPublicActivityFilterQuery query, CancellationToken cancellationToken = default) (:21-23). The query parameter is unused by design, the query record has no fields.
  • await PublicConferenceVisibility.GetPublishedEventIdsAsync(unitOfWork, cancellationToken) (:25-27) does the work. That shared helper resolves the read repository for Event (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Common/PublicConferenceVisibility.cs:40), projects e => e.Id under the predicate e => e.IsPublished with asTracking: false (PublicConferenceVisibility.cs:42-44), and materializes the sequence once so the caller embeds a stable collection EF can translate into IN (PublicConferenceVisibility.cs:46-47). Every await in this path is .ConfigureAwait(false), the codebase convention for library code.
  • The return (:29-30) wraps a new InlineSpecification<Activity, ActivityIdentifierType>(a => publishedEventIds.Contains(a.EventId)) in Result.Success<...>. InlineSpecification is the lambda-carrying specification, so no bespoke specification class is needed for a one-line criteria. The handler has no failure path: an empty published-event list is a valid answer that yields a specification matching nothing.
• Why it's built this way: the class doc (:10-15) states the alignment: the id-list shape mirrors the sponsor, speaker and session public filters, so no navigation join is required and the criteria stays translatable on any engine (ADR-018). Centralizing the id resolution in PublicConferenceVisibility rather than repeating the IsPublished projection in every public-filter handler means the definition of "published" changes in one place.
• Where it's used: injected into ActivitiesController as IQueryHandler<GetPublicActivityFilterQuery, Result<Specification<Activity, ActivityIdentifierType>>> (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.API/Controllers/Activities/ActivitiesController.cs:45) and called from the controller's GetReadSpecificationAsync override (ActivitiesController.cs:69-79), the framework read hook, which short-circuits to null for privileged readers (:71-72, guarded by IsPrivileged at :52) so Organizers and ContentEditors keep seeing activities of events still being assembled. Because the hook is the base controller's, every read action (list, paged, lookup, by-id) is scoped from that one place, and an activity the filter excludes is a 404 rather than a redacted record (:60-65). The handler is registered by convention, not explicitly: the scan in DependencyInjection (DependencyInjection.cs:133) picks up every IQueryHandler<,> in the assembly.
• Caveats / not in source: the controller maps a failed Result to null (ActivitiesController.cs:78), that is, to no filter at all, the fail-open shape the sibling public-filter handlers share; no path in this handler produces a failure today. The two-query shape (published event ids, then activities) is also two round trips by construction, and nothing in the handler or in PublicConferenceVisibility memoizes the id list, so each call re-reads it.

ConferenceCategoryUpdateRequest

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Categories.UseCases.Update · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Categories/UseCases/Update/ConferenceCategoryUpdateRequest.cs:4 · Level 0 · record

• What it is: the request body of PUT /conferencecategories/{id}, three properties describing the new state of a Category: a Title, a Sort order, and an optional Type.
• Depends on: nothing first-party and nothing external. It is a plain payload record with no domain types, no base class, and no marker interface (ConferenceCategoryUpdateRequest.cs:1-14 is the whole file).
• Concept introduced: the update request as payload only. [Rubric §9, API & Contract Design] assesses whether the contract crossing the wire says exactly what the caller controls and nothing more. An update needs three things: which row, what the caller last saw, and what to write. Only the third is in this record. The row id arrives on the route, and the concurrency token arrives in the If-Match header (ADR-035), pulled out by SupportsIfMatchAttribute.RequiredToken(HttpContext) in the action (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.API/Controllers/Categories/ConferenceCategoriesController.cs:124). The framework's UpdateEntityCommand<TEntity, TUpdateRequest, TIdentifierType> marries the three into one dispatchable object (ConferenceCategoriesController.cs:127). [Rubric §11, Security]: a token that lives in the header rather than the body cannot be dropped by a caller who simply omits a property, because a conditional write with no precondition never reaches a handler at all (428 Precondition Required, declared at ConferenceCategoriesController.cs:118).
• Walkthrough: public record class ConferenceCategoryUpdateRequest (:4, deliberately not sealed, though nothing derives from it today) with three init members. Title is required string (:7), so the record cannot be constructed without one and a JSON body that omits it fails model binding before any validator runs. Sort is a plain int (:10) that defaults to 0. Type is string? (:13), documented as an optional discriminator such as "session" or "speaker".
• Why it's built this way: the three members line up one for one with the aggregate's guarded mutation, Category.Update(string title, int sort, string? type) (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Domain/Categories/Category.cs:84), which is what lets ConferenceCategoryUpdateApplier be four lines of delegation with no field-by-field copying. Keeping the record free of framework markers is what lets one generic command and one generic handler serve it, with the mapping explicit rather than reflective (ADR-001).
• Where it's used: bound from the body by ConferenceCategoriesController's UpdateAsync (ConferenceCategoriesController.cs:119-135); named as the TUpdateRequest argument of AddEntityCrud (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/DependencyInjection.cs:143), which is what closes the framework's update handler and validator bridge over it; validated by ConferenceCategoryUpdateRequestValidator; applied to the aggregate by ConferenceCategoryUpdateApplier. Its create-side sibling is ConferenceCategoryCreateRequest, which needs no separate command because a create carries its identity in the body.

GetPublicEventSpeakerFilterQuery

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Events.UseCases.GetPublicEventSpeakerFilter · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Events/UseCases/GetPublicEventSpeakerFilter/GetPublicEventSpeakerFilterQuery.cs:10 · Level 0 · record (sealed)

• What it is: a parameterless marker query asking for the filter that limits EventSpeaker junction rows to the ones a non-privileged caller may read. The whole type is one line: public sealed record GetPublicEventSpeakerFilterQuery; (GetPublicEventSpeakerFilterQuery.cs:10).
• Depends on: nothing first-party, nothing external. It is an empty record with no positional parameters.
• Concept: none new. The marker-query shape is taught under GetPublicSessionFilterQuery, and the visibility rules themselves are defined once in PublicConferenceVisibility. What this query adds is a junction with two parents. The doc comment (GetPublicEventSpeakerFilterQuery.cs:3-9) states both legs and the leak each one closes: a row is readable only when its parent event is published (BR-108), because otherwise the join endpoints would list the speakers of an unannounced event and reveal that it exists, AND when its parent speaker is publicly visible (BR-239), because otherwise the association endpoint would hand back the whole Sessionize-imported roster that the speaker list itself hides. [Rubric §11, Security] assesses whether an anonymous surface can be used to infer the existence of content the caller may not read; a join row with two parents can leak through either of them.
• Walkthrough: no members. Every line of behavior lives in GetPublicEventSpeakerFilterHandler.
• Why it's built this way: the rules belong to the two parents, not to the join row, so the query carries no arguments and the handler derives its answer from the shared resolver instead of restating either rule.
• Where it's used: handled by GetPublicEventSpeakerFilterHandler; injected into EventSpeakersController as an IQueryHandler<in TQuery, TResult> (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.API/Controllers/Events/EventSpeakersController.cs:51) and constructed inside that controller's override of the framework read hook GetReadSpecificationAsync (EventSpeakersController.cs:78), which returns null for privileged readers (:75-76) and the specification for everyone else. Because the hook is a single override, all four [AllowAnonymous] reads inherit the filter without restating it: the unpaged list (:84-92), the paged list (:94-107), the lookup (:113-119), and the by-id read (:121-130).

SessionizeCategoryItem

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Events.Sessionize · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Events/Sessionize/SessionizeModels.cs:60 · Level 0 · record (sealed)

• What it is: the leaf DTO for one category value from the Sessionize "View All" API (for example "Beginner" under the "Level" category, or ".NET" under "Track"): an Id, a Name, and a Sort order.
• Depends on: System.Text.Json.Serialization ([JsonPropertyName], BCL) only.
• Concept introduced, the external-API contract DTO. [Rubric §9, API & Contract Design] assesses whether contracts crossing a boundary are explicit; [Rubric §32, Dependency & Supply-Chain] assesses controlling the shape of data arriving from a third party. The whole Sessionize* family in this one file models the JSON wire format of the external system the conference agenda is imported from. Every member of the family follows the same three rules: it is a sealed record, every property is init-only, and every property carries a [JsonPropertyName("...")] mapping the C# name onto the exact Sessionize field (SessionizeModels.cs:62-69). Reference-typed properties get a non-null default (Name { get; init; } = string.Empty at line 66, collections = []), so a payload missing a field deserializes to an empty value rather than a null the import code would have to guard. Modeling the external contract as its own dedicated immutable type, instead of binding straight onto domain entities, is the anti-corruption discipline: the outside shape is captured here and translated into the domain by the sync strategies. The remaining Sessionize* sections cross-reference back to this one rather than repeating the shape.
• Walkthrough: three init properties, Id (int, line 63), Name (string, empty default, line 66), Sort (int, line 69), each JSON-mapped by the attribute on the line above it. No behavior at all; it is a pure data-transfer record.
• Why it's built this way: record gives structural equality and a compact declaration (the same reasoning as the ValueObject discussion), and init plus non-null defaults means System.Text.Json can populate it while callers can never mutate it afterward.
• Where it's used: nested inside SessionizeCategory's Items (SessionizeModels.cs:56); consumed by the category import path, CategorySyncStrategy.

SessionizeLink

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Events.Sessionize · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Events/Sessionize/SessionizeModels.cs:126 · Level 0 · record (sealed)

• What it is: the DTO for one speaker social link from Sessionize: a Title, a Url, and a LinkType (for example "Twitter" or "LinkedIn").
• Depends on: System.Text.Json.Serialization (BCL) only.
• Concept: an external-API contract DTO, the pattern taught on SessionizeCategoryItem. [Rubric §9, API & Contract Design].
• Walkthrough: three init string properties, all empty-defaulted and JSON-mapped: Title (line 129), Url (line 132), LinkType (line 135).
• Why it's built this way: Url is a plain string, not a Uri. Keeping it a string means a non-canonical value from Sessionize cannot fail deserialization at the wire boundary; any parsing or validation happens later, in the import path, where a bad value can be reported as a warning instead of an exception.
• Where it's used: nested inside SessionizeSpeaker's Links collection (SessionizeModels.cs:110), read by SpeakerSyncStrategy.

SessionizeQuestion

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Events.Sessionize · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Events/Sessionize/SessionizeModels.cs:25 · Level 0 · record (sealed)

• What it is: the DTO for one custom-question definition from Sessionize (the question itself, not an answer to it): Id, Question text, QuestionType, and a Sort order.
• Depends on: System.Text.Json.Serialization (BCL) only.
• Concept: an external-API contract DTO (SessionizeCategoryItem). [Rubric §9, API & Contract Design].
• Walkthrough: four init properties, Id (int, line 28), Question (string, empty default, line 31), QuestionType (string, empty default, line 34), Sort (int, line 37). QuestionType arrives as a free-form string, so the import decides how to interpret it rather than the wire model constraining it to an enum.
• Where it's used: nested inside SessionizeResponse's Questions (SessionizeModels.cs:21); imported by QuestionSyncStrategy. Its answers are carried separately, by SessionizeQuestionAnswer.

SessionizeQuestionAnswer

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Events.Sessionize · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Events/Sessionize/SessionizeModels.cs:192 · Level 0 · record (sealed)

• What it is: the DTO for one answer to a Sessionize custom question: the QuestionId it answers and its AnswerValue.
• Depends on: System.Text.Json.Serialization (BCL) only.
• Concept: an external-API contract DTO (SessionizeCategoryItem). [Rubric §9, API & Contract Design].
• Walkthrough: two init properties, QuestionId (int, line 195) and AnswerValue (string, empty default, line 198). The answer points back at its question by id rather than nesting the question definition, which is why the same answer record can hang off two different parents.
• Where it's used: nested inside both SessionizeSpeaker's (SessionizeModels.cs:122) and SessionizeSession's (SessionizeModels.cs:170) QuestionAnswers collections.

SessionizeRoom

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Events.Sessionize · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Events/Sessionize/SessionizeModels.cs:73 · Level 0 · record (sealed)

• What it is: the DTO for one room from Sessionize: Id, Name, Sort.
• Depends on: System.Text.Json.Serialization (BCL) only.
• Concept: an external-API contract DTO (SessionizeCategoryItem). [Rubric §9, API & Contract Design].
• Walkthrough: three init properties, Id (int, line 76), Name (string, empty default, line 79), Sort (int, line 82). Structurally identical to SessionizeCategoryItem; the two are kept as distinct types (rather than one shared "named thing" record) so a change on either side of the Sessionize contract cannot silently propagate to the other import path.
• Where it's used: nested inside SessionizeResponse's Rooms (SessionizeModels.cs:12); imported by RoomSyncStrategy into the domain Room. Sessions reference a room by RoomId (SessionizeModels.cs:173), not by nesting this record.

SessionizeCategory

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Events.Sessionize · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Events/Sessionize/SessionizeModels.cs:41 · Level 1 · record (sealed)

• What it is: the DTO for one Sessionize category (for example "Level" or "Track"), owning the nested list of its SessionizeCategoryItem values.
• Depends on: SessionizeCategoryItem (its Items collection); System.Text.Json.Serialization (BCL).
• Concept: an external-API contract DTO (SessionizeCategoryItem). This is the first Sessionize* record that nests another, which is exactly why it sits one dependency level up. [Rubric §9, API & Contract Design].
• Walkthrough: five init properties. Id (int, line 44), Title (string, empty default, line 47), and Sort (int, line 50) are the flat fields; Type is string? (line 53), so an absent JSON field stays null rather than being flattened to an empty string; Items is IReadOnlyList<SessionizeCategoryItem> defaulted to the collection expression [] (line 56), so a category with no values deserializes to an empty list. Exposing the collection as IReadOnlyList<T> (not List<T>) keeps the record immutable in practice as well as by init.
• Where it's used: nested inside SessionizeResponse's Categories (SessionizeModels.cs:9); both the category and its items are reconciled against the domain Category by CategorySyncStrategy.

SessionizeSession

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Events.Sessionize · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Events/Sessionize/SessionizeModels.cs:139 · Level 1 · record (sealed)

• What it is: the richest Sessionize DTO: one conference session with its schedule, room, speaker references, category assignments, question answers, and live/recording metadata.
• Depends on: SessionizeQuestionAnswer (its QuestionAnswers list, line 170); System.Text.Json.Serialization (BCL).
• Concept: an external-API contract DTO (SessionizeCategoryItem), here at full width. [Rubric §9, API & Contract Design].
• Walkthrough: sixteen init properties (SessionizeModels.cs:141-188). Five groups are worth knowing:
  1. Id (int, line 143) is the only property in the whole file annotated [JsonNumberHandling(JsonNumberHandling.AllowReadingFromString)] (line 142). Sessionize sometimes serializes a session id as a JSON string rather than a number, and that one attribute is what stops the whole import from failing on it.
  2. StartsAt and EndsAt are DateTime? (lines 152 and 155), so an unscheduled session round-trips with nulls instead of a deserialization error. SessionSyncStrategy validates the pair rather than the wire model doing it: ValidateSessionTimes (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Events/UseCases/RefreshFromSessionize/SessionSyncStrategy.cs:53) warns when a start falls before the event's start date and when an end falls after its end date (BR-86, :55-64), and warns on a zero or negative duration while storing the value as-is per BR-122 (:66-70).
  3. Speakers is IReadOnlyList<Guid> (line 164), CategoryItems is IReadOnlyList<int> (line 167), and RoomId is int? (line 173): the session references other entities by their Sessionize ids instead of nesting the full objects, so those cross-references are resolved during import against the already-imported speakers, category items, and rooms.
  4. Description, LiveUrl, RecordingUrl, and Status are nullable strings (lines 149, 176, 179, 182); LiveUrl and RecordingUrl stay string for the same reason as SessionizeLink's Url. Title (line 146) is the one non-nullable string, empty-defaulted.
  5. Four booleans classify the session: IsServiceSession (line 158) and IsPlenumSession (line 161) mark non-talk and plenary slots, IsInformed (line 185) and IsConfirmed (line 188) carry the speaker-communication state Sessionize tracks.
• Why it's built this way: the id-reference lists mirror how Sessionize normalizes its own payload; keeping the DTO faithful to that shape (rather than pre-joining it) means the wire model stays a mechanical translation and every judgement call lives in the sync strategies, where it can emit a warning.
• Where it's used: nested inside SessionizeResponse's Sessions (SessionizeModels.cs:18); imported by SessionSyncStrategy under RefreshFromSessionizeHandler.

SessionizeSpeaker

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Events.Sessionize · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Events/Sessionize/SessionizeModels.cs:86 · Level 1 · record (sealed)

• What it is: the DTO for one speaker from Sessionize, with profile fields, social SessionizeLinks, question answers, and id references to the speaker's sessions and category items.
• Depends on: SessionizeLink (Links), SessionizeQuestionAnswer (QuestionAnswers); System.Text.Json.Serialization (BCL).
• Concept: an external-API contract DTO (SessionizeCategoryItem). [Rubric §9, API & Contract Design].
• Walkthrough: twelve init properties (SessionizeModels.cs:88-122). Id is a Guid (line 89), unlike the int ids of every other Sessionize entity in this file. The optional profile fields Bio (line 98), TagLine (line 101), ProfilePicture (line 104), and FullName (line 116) are nullable strings, while FirstName (line 92) and LastName (line 95) are empty-defaulted non-nullable ones. IsTopSpeaker is a bool (line 107). Four collections, Links (line 110), Sessions (IReadOnlyList<int>, line 113), CategoryItems (IReadOnlyList<int>, line 119), and QuestionAnswers (line 122), are all IReadOnlyList<T> defaulted to [].
• Why it's built this way: the Guid speaker id lines up with the Conference module's SpeakerIdentifierType = Guid alias, so the import can carry a Sessionize speaker id straight into a domain Speaker key without a conversion or a lookup table. That both FullName and the FirstName/LastName pair exist is Sessionize's redundancy, not the module's: the wire model keeps both and lets SpeakerSyncStrategy choose.
• Where it's used: nested inside SessionizeResponse's Speakers (SessionizeModels.cs:15); imported by SpeakerSyncStrategy, which takes the record directly as a parameter (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Events/UseCases/RefreshFromSessionize/SpeakerSyncStrategy.cs:101-102). One consequence of that import is load-bearing elsewhere in this chapter: every synced speaker without an active link gets an EventSpeaker row (SpeakerSyncStrategy.cs:59), which is why GetPublicEventSpeakerFilterHandler cannot treat that junction as an acceptance signal.

SessionizeResponse

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Events.Sessionize · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Events/Sessionize/SessionizeModels.cs:6 · Level 2 · record (sealed)

• What it is: the top-level envelope for the Sessionize "View All" API response, holding the five parallel collections (Categories, Rooms, Speakers, Sessions, Questions) that make up an entire conference import payload.
• Depends on: SessionizeCategory, SessionizeRoom, SessionizeSpeaker, SessionizeSession, SessionizeQuestion; System.Text.Json.Serialization (BCL).
• Concept: the root of the external-API contract DTO tree that SessionizeCategoryItem taught. [Rubric §9, API & Contract Design]. This is the object ISessionizeService returns and the single input every Sessionize sync strategy reads from.
• Walkthrough: five init IReadOnlyList<...> properties, each defaulted to [] and JSON-mapped to the lower-cased Sessionize field name: Categories (line 9), Rooms (line 12), Speakers (line 15), Sessions (line 18), Questions (line 21). "View All" is Sessionize's denormalized endpoint: it returns every entity kind in one document, which is why this envelope has one collection per kind rather than a paged, per-type shape.
• Why it's built this way: one immutable envelope makes the import easy to reason about, the strategies receive the whole snapshot at once and reconcile the domain against it; and the empty-list defaults mean a payload missing a section is still a valid, non-null response the strategies can iterate over without null checks.
• Where it's used: returned (nullable) by ISessionizeService; carried to the sync strategies as the required Response property of SessionizeSyncContext (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Events/UseCases/RefreshFromSessionize/SessionizeSyncContext.cs:13), which RefreshFromSessionizeHandler builds under the RefreshFromSessionizeCommand use case.

ISessionizeService

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Events.Sessionize · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Events/Sessionize/ISessionizeService.cs:6 · Level 3 · interface

• What it is: the one-method contract for fetching a whole conference from the Sessionize "View All" API, returning a SessionizeResponse or null when the response is empty.
• Depends on: SessionizeResponse (its return type). Nothing else, no HttpClient, no options type.
• Concept introduced, the outbound-port interface (dependency inversion at an external boundary). [Rubric §3, Clean Architecture] assesses whether the Application layer depends only on abstractions it owns, with concrete adapters living further out; [Rubric §7, Microservices Readiness] assesses isolating third-party calls behind a swappable boundary. Here the Application layer declares what it needs from Sessionize (this interface), while the HTTP client that actually calls the API lives in Conference Infrastructure and implements it: SessionizeService, registered as a typed client with the base address https://sessionize.com/api/v2/ via services.AddHttpClient<ISessionizeService, SessionizeService>(...) (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Infrastructure/DependencyInjection.cs:26-28). That inversion is what keeps the import use case exercisable without a network: the integration tier substitutes FakeSessionizeService (MMCA.ADC/Tests/Integration/MMCA.ADC.Conference.IntegrationTests/Infrastructure/FakeSessionizeService.cs:12) and feeds a canned response.
• Walkthrough: a single method, Task<SessionizeResponse?> GetAllAsync(string sessionizeCode, CancellationToken cancellationToken = default) (ISessionizeService.cs:12). sessionizeCode is the per-event Sessionize code (the XML doc gives the example "kqf8l42a", line 9); the nullable return signals an empty or absent response instead of throwing, so the caller decides whether an empty import is an error; and the defaulted trailing CancellationToken follows the codebase convention that every async boundary is cancelable.
• Why it's built this way: a narrow, single-purpose port is the smallest surface the import needs, which makes both the real HTTP adapter and its test double trivial to write and keeps retry and timeout policy an Infrastructure concern.
• Where it's used: constructor-injected into RefreshFromSessionizeHandler (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Events/UseCases/RefreshFromSessionize/RefreshFromSessionizeHandler.cs:22) and called there as GetAllAsync(@event.SessionizeCode, cancellationToken) (RefreshFromSessionizeHandler.cs:82). Note that it is not registered by this layer's DependencyInjection: the Application layer owns the interface, Infrastructure owns and registers the implementation.

ConferenceCategoryUpdateApplier

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Categories.UseCases.Update · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Categories/UseCases/Update/ConferenceCategoryUpdateApplier.cs:12 · Level 7 · class (sealed)

• What it is: the four-line adapter that takes a ConferenceCategoryUpdateRequest and a loaded Category and calls the aggregate's own guarded Update method, so the framework's generic update handler never has to know a category field name.
• Depends on: IEntityUpdateApplier<TEntity, TUpdateRequest, TIdentifierType> from MMCA.Common.Application.Interfaces (:2,13), the Category aggregate (:1,13), ConferenceCategoryUpdateRequest (:13), and Result from MMCA.Common.Shared.Abstractions (:3,16). ConferenceCategoryIdentifierType is the module's identifier alias.
• Concept introduced: the update applier, the write-side twin of the create mapper. [Rubric §4, DDD] assesses whether the aggregate keeps its invariants and its events; [Rubric §1, SOLID] assesses whether a type has exactly one reason to change. The framework ships one generic update handler, UpdateEntityHandler<TEntity, TEntityDTO, TIdentifierType, TUpdateRequest>, which owns loading the row, applying the optimistic-concurrency token, and saving. It cannot own the mutation, because the mutation is entity-specific. The applier interface is the extension point that closes the gap: the mapper owns "request to a new aggregate", the applier owns "request onto an existing aggregate" (MMCA.Common/Source/Core/MMCA.Common.Application/Interfaces/Mapping/IEntityDTOMapper.cs:62-75). Two details of that contract are worth reading once. The applier answers with a bare Result rather than a new entity, because the instance handed in is the tracked one: a successful apply has already mutated it in place, and a refusal must leave it untouched so nothing reaches the database (IEntityDTOMapper.cs:70-74). And the applier is async-shaped (Task<Result>, IEntityDTOMapper.cs:91) even though this one has nothing to await, so that an applier that does need a lookup fits the same contract.
• Walkthrough:
  1. The class declaration binds the three type arguments once: IEntityUpdateApplier<Category, ConferenceCategoryUpdateRequest, ConferenceCategoryIdentifierType> (:13). That closed triple is what the DI scan matches on and what closes the generic handler over this aggregate.
  2. ApplyAsync (:16) guards both arguments with ArgumentNullException.ThrowIfNull (:18-19). These are programming-error guards, not validation: a null here means the framework handed the applier something impossible, which is an exception rather than a Result failure.
  3. The body is one delegation, wrapped in Task.FromResult because there is nothing to await: entity.Update(request.Title, request.Sort, request.Type) (:21-24). Nothing in this file writes a property.
  4. Inside the aggregate, Category.Update (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Domain/Categories/Category.cs:84) is where the rules live: it combines CategoryInvariants.EnsureTitleIsValid and returns the failure before touching state (Category.cs:86-89), assigns the three properties (:91-93), and raises CategoryChanged with DomainEntityState.Updated (:95). A refused title therefore never mutates the tracked entity, which is exactly the contract the interface documents.
• Why it's built this way: the module's DependencyInjection spells out the trade explicitly (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/DependencyInjection.cs:135-143). One AddEntityCrud<Category, ConferenceCategoryDTO, ConferenceCategoryIdentifierType, ConferenceCategoryCreateRequest, ConferenceCategoryUpdateRequest>() call registers the create, update and delete handlers closed over this aggregate's types (MMCA.Common/Source/Core/MMCA.Common.Application/DependencyInjection.cs:339-353), and the call is deliberately placed after the module scan because it uses TryAdd: the module's own CreateConferenceCategoryHandler keeps the create verb, while the update and delete verbs, which nothing in this assembly registers, come from the framework. The result is that a plain-CRUD aggregate costs one registration line plus this applier, and the domain keeps every invariant and every event. Compare the Speaker path in the same file (DependencyInjection.cs:146-152), which needs the command-aware applier because BR-214 carries state the request body must never hold.
• Where it's used: picked up by the convention scan services.ScanModuleApplicationServices<ClassReference>() (DependencyInjection.cs:132), which registers every IEntityUpdateApplier<,,> implementation (MMCA.Common/Source/Core/MMCA.Common.Application/DependencyInjection.cs:227); resolved as a constructor dependency of the generic UpdateEntityHandler (MMCA.Common/Source/Core/MMCA.Common.Application/UseCases/Crud/UpdateEntityHandler.cs:50), which serves the PUT /conferencecategories/{id} action on ConferenceCategoriesController (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.API/Controllers/Categories/ConferenceCategoriesController.cs:39 and :125-127).
• Testing: ConferenceCategoryUpdateApplierTests (MMCA.ADC/Tests/Modules/Conference/MMCA.ADC.Conference.Application.Tests/Categories/UseCases/ConferenceCategoryUpdateApplierTests.cs:19) exercises the applier the way it actually runs, composed inside a real UpdateEntityHandler over a mocked repository (:29-32) rather than in isolation. Four tests: the happy path asserting the DTO carries all three updated fields (:48), a not-found id mapping to ErrorType.NotFound (:69), a whitespace-only title that fails the domain invariant and, crucially, asserts SaveChangesAsync was never called (:87-108), and the mirror assertion that a valid request saves exactly once (:111). [Rubric §14, Testability]: the third test is the one that protects the "a refusal leaves the entity untouched" half of the applier contract, which is the half a hand-written applier is most likely to break.

ConferenceCategoryUpdateRequestValidator

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Categories.UseCases.Update · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Categories/UseCases/Update/ConferenceCategoryUpdateRequestValidator.cs:7 · Level 8 · class (sealed)

• What it is: the FluentValidation validator for ConferenceCategoryUpdateRequest, run by the pipeline before the update handler executes. Its entire body is one Include.
• Depends on: AbstractValidator<T> (FluentValidation, :1,7), ConferenceCategoryUpdateRequest (:7), and the shared ConferenceCategoryTitleRules<T> rule set from MMCA.ADC.Conference.Application.Categories.Validation (:2,10).
• Concept: none new; this is Include composition (taught in group 06) in its smallest possible form, plus one piece of wiring worth tracing once. The validator is written against the request, but the object the pipeline dispatches is an UpdateEntityCommand<TEntity, TUpdateRequest, TIdentifierType>. The bridge is registered by the same AddEntityCrud call that registers the handler: a CommandRequestValidator<TCommand, TRequest> closed over the command and this request (MMCA.Common/Source/Core/MMCA.Common.Application/DependencyInjection.cs:351-353, rationale at :308-317). The command is a closed generic built at registration time, so the module scan's reflection bridge cannot see it, which is why the framework registers it explicitly and why TryAdd still lets a hand-written command validator win. [Rubric §24, Forms/Validation/UX Safety] assesses whether input constraints are single-sourced and consistently applied; [Rubric §1, SOLID]: this class's only job is composition, so a title-rule change never has to be found in two files.
• Walkthrough: sealed class ConferenceCategoryUpdateRequestValidator : AbstractValidator<ConferenceCategoryUpdateRequest> (:7), with an expression-bodied constructor (:9-10) folding in a single parameterized rule set: Include(new ConferenceCategoryTitleRules<ConferenceCategoryUpdateRequest>(p => p.Title)). The rule set itself (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Categories/Validation/ConferenceCategoryValidationRules.cs:14-21) attaches two rules with stable error codes: NotEmpty() under Category.Title.Required (:19) and MaximumLength(CategoryInvariants.TitleMaxLength) under Category.Title.MaxLength (:20). That max length is not a literal: CategoryInvariants reads it from ConferenceCategoryDTO.TitleMaxLength (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Domain/Categories/CategoryInvariants.cs:18), which the EF configuration and the Blazor input caps also bind to, so the number is declared once and enforced at every layer.
• Why it's built this way: Sort and Type carry no rules here, and that is a decision rather than a gap. Sort has no field-level business constraint on a category (its child items do get one, through CategoryItemSortRules<T> over the framework's NonNegativeIntRules<T>), and Type is a free-form optional discriminator. The title check is deliberately duplicated between here and the aggregate: this validator gives the caller a 400 with a stable error code before the transaction opens, while CategoryInvariants.EnsureTitleIsValid inside Category.Update is the invariant that holds even when the aggregate is mutated from a path that never saw a request. [Rubric §3, Clean Architecture] assesses whether each layer holds the checks it is entitled to hold.
• Where it's used: registered by the module scan (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/DependencyInjection.cs:133) as IValidator<ConferenceCategoryUpdateRequest>, then reached through the command bridge above whenever PUT /conferencecategories/{id} dispatches (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.API/Controllers/Categories/ConferenceCategoriesController.cs:126-128). The same ConferenceCategoryTitleRules<T> object is included by the create-side ConferenceCategoryCreateRequestValidator against a different request type, which is the whole point of parameterizing the rule set by T.
• Testing: ConferenceCategoryUpdateRequestValidatorTests (MMCA.ADC/Tests/Modules/Conference/MMCA.ADC.Conference.Application.Tests/Categories/Validation/ConferenceCategoryUpdateRequestValidatorTests.cs:6), two tests using FluentValidation's TestValidateAsync helper: a valid request produces no errors (:20), and a request built with with { Title = string.Empty } produces an error on Title (:31). The max-length branch is not covered here.

GetPublicEventSpeakerFilterHandler

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Events.UseCases.GetPublicEventSpeakerFilter · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Events/UseCases/GetPublicEventSpeakerFilter/GetPublicEventSpeakerFilterHandler.cs:22 · Level 11 · class (sealed)

• What it is: the handler for GetPublicEventSpeakerFilterQuery. It asks PublicConferenceVisibility twice, once for the published event ids and once for the visible speaker ids, and returns an EventSpeaker.EventId IN (...) AND EventSpeaker.SpeakerId IN (...) specification.
• Depends on: IUnitOfWork (:23, injected only to hand on to the resolver), PublicConferenceVisibility, InlineSpecification<TEntity, TIdentifierType> and its base Specification<TEntity, TIdentifierType>, EventSpeaker, and Result. It implements IQueryHandler<in TQuery, TResult> to Result<Specification<EventSpeaker, EventSpeakerIdentifierType>> (:24).
• Concept introduced: the two-parent junction filter. [Rubric §11, Security]. The other public filters in this family each derive from a single parent: GetPublicRoomFilterHandler follows the event, GetPublicSpeakerFilterHandler follows the speaker's eligible sessions. This one ANDs two independent legs, and the remarks explain why the second is not redundant (:16-21): the Sessionize import writes an EventSpeaker row for every speaker in the response, which you can read in SpeakerSyncStrategy itself, where every synced speaker without an active link gets context.Event.AddEventSpeaker(null, ss.Id) (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Events/UseCases/RefreshFromSessionize/SpeakerSyncStrategy.cs:59). An event-only filter would therefore republish the entire imported roster through the association endpoint, which is exactly what the public speaker list hides.
• Concept: the duplicate scalar read, taken deliberately. [Rubric §12, Performance & Scalability]. The inline comment (:35-37) records a cost decision rather than an oversight. The junction read carries no event context, so the speaker rule spans every published event; both resolver calls read the Event table, described there as bounded at single-digit rows; and the duplicate scalar read was judged cheaper than threading the already-resolved ids through the shared resolver's signature. The trade-off is in the open: one extra projection query per request in exchange for keeping PublicConferenceVisibility's API narrow.
• Walkthrough:
  1. Resolve the published event ids: PublicConferenceVisibility.GetPublishedEventIdsAsync(unitOfWork, cancellationToken) (:31-33). Inside the resolver that is one scalar projection of Event.Id filtered by IsPublished, read untracked (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Common/PublicConferenceVisibility.cs:42-44), then materialized once so the caller embeds a stable collection EF can translate to IN (PublicConferenceVisibility.cs:46-47).
  2. Resolve the visible speaker ids: GetVisibleSpeakerIdsAsync(unitOfWork, cancellationToken: cancellationToken) (:38-40), with the optional event scope left at its default and spelled out with a named argument so it reads as a decision rather than an omission. Inside, that is the BR-239 chain: the published events (PublicConferenceVisibility.cs:109), the optional narrowing to one scoped event (:113-117), an empty answer when the scope is empty (:119-120), the eligible sessions inside that scope (:122-124), then the SessionSpeaker join projected down to distinct speaker ids (:126-133).
  3. Wrap es => eventIds.Contains(es.EventId) && speakerIds.Contains(es.SpeakerId) in an InlineSpecification<TEntity, TIdentifierType> and return Result.Success (:42-44). There is no failure path: the handler cannot fail on its own terms.
• Why it's built this way: the summary states the shape (:10-15) and the remarks give the reason for the second leg (:16-21). Both legs are id lists turned into Contains, never navigation joins, so the criteria stays translatable on any provider (ADR-018), and deriving both from the shared resolver means the junction cannot drift away from the entities whose visibility it follows. The resolver's own remarks say why the EventSpeaker join is never read back as a visibility grant (PublicConferenceVisibility.cs:97-103).
• Where it's used: EventSpeakersController injects it as an IQueryHandler (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.API/Controllers/Events/EventSpeakersController.cs:51) and calls it from one place, its override of the framework read hook GetReadSpecificationAsync (:72-82), which short-circuits to null for privileged readers (:75-76, backed by currentUserService.IsPrivilegedConferenceReader() at :58). Because the hook is inherited by every read action, the four [AllowAnonymous] reads below it are attribute-only passthroughs with empty bodies (:84-92, :94-107, :113-119, :121-130), and the doc comment says so (:65-70). All four also sit behind [OutputCache(PolicyName = "EventsCache")]. Note that the class-level [HasPermission(ConferencePermissions.EventsManage)] (:46) is what those four actions override, which is exactly why the handler has to carry the visibility rules itself. The CSV export is handled differently: rather than filter it, the controller forbids it outright for non-privileged callers (:139-153, rationale at :132-137), because the inherited export streams with no specification.
• Testing: GetPublicEventSpeakerFilterHandlerTests (MMCA.ADC/Tests/Modules/Conference/MMCA.ADC.Conference.Application.Tests/Events/UseCases/GetPublicEventSpeakerFilter/GetPublicEventSpeakerFilterHandlerTests.cs:19), six tests on the shared HandlerTestBase<THandler>: the success shape (:74), a row whose event is published and whose speaker is visible (:83), a row on an unpublished event (:94), a row of a hidden speaker on a published event (:105), a world where no speaker is visible (:118), and one that captures the predicate the handler hands to the Event projection, compiles it, and asserts it accepts a published event and rejects an unpublished one (:128). One fixture detail is a property of the entity rather than of the test: EventSpeaker.EventId is get-only and written by EF, so a row built through the factory in memory carries the default id, and the fixture uses default as its row event id (:21-22). [Rubric §14, Testability]: the speaker leg is the rule most likely to be dropped as redundant, and :105 is the test that would catch it.
• Caveats / not-in-source: the controller maps a failed Result to null, meaning no filter: return result.IsSuccess ? result.Value : null; (EventSpeakersController.cs:81), which would widen the read rather than narrow it. Nothing in this handler can produce that failure today, so the exposure is latent rather than live, but it is the opposite of the fail-closed default the rest of the visibility code takes, and the same shape appears on the room controller. Both id lists are also materialized into the predicate, so the two IN lists grow with the number of published events and of publicly visible speakers; nothing in this file bounds either.

GetPublicRoomFilterQuery

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Events.UseCases.GetPublicRoomFilter · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Events/UseCases/GetPublicRoomFilter/GetPublicRoomFilterQuery.cs:14 · Level 0 · record (sealed)

• What it is: a parameterless marker query asking for the filter that limits Room rows to the ones a non-privileged caller may read: a room is publicly visible when the event it belongs to is published (BR-108). The whole type is one line, public sealed record GetPublicRoomFilterQuery(); (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Events/UseCases/GetPublicRoomFilter/GetPublicRoomFilterQuery.cs:14).
• Depends on: nothing first-party, nothing external.
• Concept: none new. The marker-query shape is taught under GetPublicSessionFilterQuery; the rule it names is resolved once in PublicConferenceVisibility. [Rubric §11, Security] assesses whether an anonymous surface leaks the existence or the detail of content the caller may not read. The doc comment names the concrete exposure this query closes (GetPublicRoomFilterQuery.cs:3-8): rooms of an unpublished event stay hidden, so an event still being assembled does not publish its floor plan, room names, or capacities before the agenda is announced.
• Walkthrough: no members. Note the declaration-style difference from its sibling in this same group: this one is written with an empty parameter list, GetPublicRoomFilterQuery(), which declares a primary constructor, while GetPublicEventSpeakerFilterQuery is written without one, GetPublicEventSpeakerFilterQuery; (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Events/UseCases/GetPublicEventSpeakerFilter/GetPublicEventSpeakerFilterQuery.cs:10). Both are constructed identically at the call site as new X(), so the difference is cosmetic; it is worth knowing only so you do not read meaning into it.
• Why it's built this way: the remarks (GetPublicRoomFilterQuery.cs:9-13) record the design choice behind the shape of the answer. Room carries a real EventId column (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Domain/Events/Room.cs:38), so the rule resolves to a published-event id list and comes back as a Room.EventId IN (...) criteria. No navigation join is involved, which keeps the criteria engine-portable (ADR-018) and keeps Room's reference to Event a by-id boundary rather than a traversal.
• Where it's used: handled by GetPublicRoomFilterHandler; injected into RoomsController (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.API/Controllers/Events/RoomsController.cs:97) and constructed inside its GetReadSpecificationAsync override (RoomsController.cs:126).

SessionizeSyncResult

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Events.UseCases.RefreshFromSessionize · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Events/UseCases/RefreshFromSessionize/ISessionizeSyncStrategy.cs:21 · Level 0 · record (sealed)

• What it is: the two-number return value of one Sessionize sync step. It carries how many rows of the step's primary entity were accepted and, where a step also touches a child collection, how many of those were accepted.
• Depends on: nothing first-party, nothing external. Two int properties, both init-only.
• Concept: none new. It is a deliberately anaemic result record co-located with the contract that returns it, ISessionizeSyncStrategy (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Events/UseCases/RefreshFromSessionize/ISessionizeSyncStrategy.cs:7), rather than living in its own file. [Rubric §9, API and Contract Design] assesses whether a contract can grow without breaking its implementors: returning a record instead of a bare int means a future step can report a third number by adding one init property, and the five existing strategies keep compiling untouched.
• Walkthrough: PrimarySynced (ISessionizeSyncStrategy.cs:24) is the headline count, for example speakers synced. SecondarySynced (ISessionizeSyncStrategy.cs:27) is the optional child count, for example the category items synced alongside their categories. Neither is required, so a strategy that has nothing secondary to report constructs new SessionizeSyncResult { PrimarySynced = n } and leaves the other at its default of zero, which is what four of the five strategies do (for example RoomSyncStrategy.cs:79).
• Why it's built this way: the counts are what the organizer sees after an import, so they must mean "the domain accepted this row", not "the feed listed this row". Every strategy increments only after the aggregate call succeeded, which is why the record is filled at the end of the loop rather than from the feed's own collection sizes.
• Where it's used: returned by all five strategies; collected into a List<SessionizeSyncResult> by RefreshFromSessionizeHandler (RefreshFromSessionizeHandler.cs:123-127) and projected into RefreshFromSessionizeResultDTO (RefreshFromSessionizeHandler.cs:144-154).

SessionizeSyncWarnings

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Events.UseCases.RefreshFromSessionize · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Events/UseCases/RefreshFromSessionize/SessionizeSyncWarnings.cs:9 · Level 3 · class (internal static)

• What it is: a one-method helper the sync strategies share when they have to explain, in one short sentence, why the domain refused a row that the Sessionize feed listed.
• Depends on: Result (MMCA.Common.Shared.Abstractions, imported at SessionizeSyncWarnings.cs:1). Nothing external.
• Concept introduced, the first-error idiom. A failed Result carries a collection of Error values, but a warning line has room for one reason. FirstErrorMessage (SessionizeSyncWarnings.cs:17-18) uses a C# list pattern, result.Errors is [var first, ..], to bind the head of the collection when one exists and fall back to the literal "Unknown error" when the failure carries none. [Rubric §15, Best Practices and Code Quality] assesses whether recurring micro-logic is expressed once: five strategies needed the same sentence, so the idiom lives in one internal static method instead of five near-copies.
• Walkthrough: one member. internal static string FirstErrorMessage(Result result) (SessionizeSyncWarnings.cs:17), expression-bodied, reading the head of the collection through a pattern rather than materializing a LINQ query.
• Why it's built this way: internal and static because this is an implementation detail of a single use case, not a service. There is nothing to inject and nothing to mock, so it is a static call rather than a dependency.
• Where it's used: CategorySyncStrategy (CategorySyncStrategy.cs:104), RoomSyncStrategy (RoomSyncStrategy.cs:72), SessionSyncStrategy (SessionSyncStrategy.cs:108) and SpeakerSyncStrategy (SpeakerSyncStrategy.cs:131).
• Caveats: QuestionSyncStrategy does not use it. Its create-failure warning joins every error message with "; " instead (QuestionSyncStrategy.cs:80), so the question path reports all reasons where the other four report the first one.

RefreshFromSessionizeCommand

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Events.UseCases.RefreshFromSessionize · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Events/UseCases/RefreshFromSessionize/RefreshFromSessionizeCommand.cs:13 · Level 8 · record (sealed)

• What it is: the command that asks for one event's data to be re-pulled from Sessionize (UC-6). It is a single-parameter record carrying the event id.
• Depends on: EventIdentifierType (the module's identifier alias, see the primer), Event (used only to build the cache prefix from its full type name), ConferenceFeatures, and three pipeline markers from MMCA.Common: ICacheInvalidating, ITransactional and IFeatureGated.
• Concept: the marker-driven decorator pipeline is taught in group 5. What is worth studying here is that one small record opts into three cross-cutting behaviors at once by implementing three interfaces (RefreshFromSessionizeCommand.cs:13). [Rubric §12, Performance & Scalability] assesses whether transactions, caching and feature gating are applied declaratively rather than hand-coded per handler: the handler below contains no transaction call, no cache eviction and no feature-flag check, because all three are decided by the markers on this type. [Rubric §29, Resilience and Business Continuity] assesses whether a risky dependency can be switched off without a deploy: IFeatureGated makes the whole Sessionize integration a runtime toggle.
• Walkthrough: the positional parameter EventId (RefreshFromSessionizeCommand.cs:13). CachePrefix returns $"{typeof(Event).FullName}:" (RefreshFromSessionizeCommand.cs:16), so a successful refresh evicts the whole Event cache region rather than a single key: the import touches events, rooms, sessions, speakers, categories and questions, so a narrower eviction would leave stale reads behind. FeatureName returns ConferenceFeatures.SessionizeIntegration (RefreshFromSessionizeCommand.cs:19), whose value is the string "Conference.SessionizeIntegration" (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Shared/ConferenceFeatures.cs:15). ITransactional is what makes the five entity families commit or roll back together.
• Why it's built this way: all five sync steps write through one IUnitOfWork and one save, so a half-applied import (rooms in, sessions out) is not reachable. Sessions reference rooms and speakers, so a partial commit would leave dangling references; the transactional marker is a correctness requirement here, not a convenience.
• Where it's used: constructed by EventsController.RefreshAsync (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.API/Controllers/Events/EventsController.cs:334) and passed to the injected ICommandHandler<in TCommand, TResult> (EventsController.cs:54).

SessionizeSyncContext

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Events.UseCases.RefreshFromSessionize · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Events/UseCases/RefreshFromSessionize/SessionizeSyncContext.cs:11 · Level 8 · record (sealed)

• What it is: the single parameter object every sync step receives: the parsed feed, the target event, the unit of work the step opens repositories from, and the two accumulators (warnings, skipped count) the steps write into as they go.
• Depends on: SessionizeResponse, Event, IUnitOfWork, and List<string> (BCL).
• Concept introduced, the mutable run context behind an immutable-looking record. Four members are required ... { get; init; } (SessionizeSyncContext.cs:13-16), so the identity of the run (which feed, which event, which unit of work, which warnings list) cannot be swapped by a step. The accumulators are still mutable, in two different ways: Warnings is init-only yet holds a List<string> whose contents every step appends to, and SkippedSoftDeleted is a plain { get; set; } counter (SessionizeSyncContext.cs:19) each step increments when it meets a soft-deleted row the feed still lists (BR-136). [Rubric §1, SOLID] assesses interface and parameter-shape discipline: bundling the run state into one type is what lets ISessionizeSyncStrategy keep a two-parameter signature that never changes when one step needs an extra input.
• Walkthrough: Response (:13) is the deserialized feed. Event (:14) is the tracked aggregate the handler loaded with its Rooms and EventSpeakers navigations, which is why RoomSyncStrategy and SpeakerSyncStrategy can consult those collections without a query. UnitOfWork (:15) is the shared unit of work: every strategy resolves its repositories from it, which is what keeps all five steps inside one transaction and one change tracker. Warnings (:16) is the running list that ends up on the response DTO. SkippedSoftDeleted (:19) is the running count of soft-deleted rows skipped.
• Why it's built this way: shared mutable state is normally a smell. It is safe here for one reason visible in the orchestrator: the strategies run strictly sequentially in a foreach (RefreshFromSessionizeHandler.cs:124-127), never concurrently. That sequencing is also a hard dependency requirement (categories before speakers and sessions, rooms before sessions), so the context's design and the execution order reinforce each other.
• Where it's used: created once per command (RefreshFromSessionizeHandler.cs:115-121) and passed to each strategy's SyncAsync.
• Caveats: nothing in the type enforces the sequential assumption. List<string> and the int counter are not thread-safe, so a change that ran the independent steps in parallel would need a concurrent collection and an interlocked counter.

ISessionizeSyncStrategy

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Events.UseCases.RefreshFromSessionize · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Events/UseCases/RefreshFromSessionize/ISessionizeSyncStrategy.cs:7 · Level 9 · interface

• What it is: the one-method contract for "synchronize one entity family from the Sessionize feed into the domain". Five implementations exist, one per family: categories, rooms, questions, speakers, sessions.
• Depends on: SessionizeSyncContext and SessionizeSyncResult (the latter declared in the same file at ISessionizeSyncStrategy.cs:21).
• Concept introduced, the Strategy pattern applied to an import pipeline. [Rubric §2, Design Patterns] assesses whether a pattern solves a real structural problem instead of adding ceremony. One Sessionize payload covers five entity families with different upsert rules, different reserved-id guards and different child collections. Written as one method that would run to several hundred lines at a cyclomatic complexity the analyzers reject at error severity. Split behind this interface, each family's rules sit in their own file and the orchestrator holds only the order. [Rubric §15, Best Practices & Code Quality] assesses whether independent concerns are isolated so that a change to room handling cannot break speaker handling: the five files share nothing but this signature and the context type. [Rubric §14, Testability] assesses whether a unit can be exercised without its collaborators: each strategy is a stateless object with a single method taking a context, so a test instantiates one directly and asserts on the returned counts and the context's warnings (for example MMCA.ADC/Tests/Modules/Conference/MMCA.ADC.Conference.Application.Tests/Events/UseCases/RefreshFromSessionize/RoomSyncStrategyTests.cs:11).
• Walkthrough: one member, Task<SessionizeSyncResult> SyncAsync(SessionizeSyncContext context, CancellationToken cancellationToken) (ISessionizeSyncStrategy.cs:15). There is no Order property and no entity-type discriminator: order is the orchestrator's business, declared once in its static array.
• Why it's built this way: passing a context rather than four parameters means a step that later needs another input costs one added property on the context, not a signature change rippling through five implementations. Returning a record rather than an int gives the same freedom on the way out.
• Where it's used: implemented by CategorySyncStrategy, RoomSyncStrategy, QuestionSyncStrategy, SpeakerSyncStrategy and SessionSyncStrategy; consumed only by RefreshFromSessionizeHandler.
• Caveats: the implementations are not registered in DI. The handler holds five instances in a static readonly ISessionizeSyncStrategy[] it constructs itself (RefreshFromSessionizeHandler.cs:29-36), so "add a strategy" means editing that array, not adding a registration.

CategorySyncStrategy

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Events.UseCases.RefreshFromSessionize · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Events/UseCases/RefreshFromSessionize/CategorySyncStrategy.cs:12 · Level 10 · class (internal sealed)

• What it is: the first step of the import. It upserts Category rows and their CategoryItem children from the feed, and it runs first because speakers and sessions reference category items.

• Depends on: SessionizeSyncContext, SessionizeCategory, SessionizeCategoryItem, Category, IRepository<TEntity, TIdentifierType> resolved from the context's unit of work, and SessionizeSyncWarnings. Externals: System.Globalization for invariant-culture id formatting.

• Concept introduced, the four-phase upsert shape the other four strategies reuse. Read it once here and the remaining strategies become variations on it.

  1. Bulk pre-load. The strategy resolves the repository once (CategorySyncStrategy.cs:16), projects the feed's ids (:21) and issues a single GetByIdsAsync with includes: [nameof(Category.CategoryItems)], asTracking: true and ignoreQueryFilters: true (:22-27), then indexes the result by id (:28). One query replaces N GetByIdAsync calls. [Rubric §12, Performance and Scalability] assesses whether repeated data access is batched: a full ADC re-import walks hundreds of feed rows, so an id-at-a-time lookup would be an N+1 against the same table.
  2. Discriminate. For each feed row (:32): if a stored row exists and is soft-deleted, bump context.SkippedSoftDeleted and skip (:36-40, BR-136). If it exists and is live, call the aggregate's Update (:42). If it does not exist, go to the Create factory (:99).
  3. Sync children. SyncCategoryItems (:62-90) compares feed items against the loaded CategoryItems collection by id, skips soft-deleted ones (:71-75), and routes the rest to UpdateCategoryItem or AddCategoryItem on the parent aggregate (:79-83), never to a child repository.
  4. Batch add and report. New categories accumulate in a local list and are flushed with one AddRangeAsync (:54-57), then the counts are returned (:59).

  [Rubric §4, DDD] assesses whether invariants stay inside aggregates: every mutation in this file is a call on Category, and category items are only ever reached through their parent, so the aggregate boundary holds even under a bulk import.

• Walkthrough of the specifics: CreateNewCategory (:92-118) is where the failure policy shows. Category.Create returns a Result; on failure the strategy appends a warning naming the title and id and quoting SessionizeSyncWarnings.FirstErrorMessage (:104), then returns without counting the row. On success it adds every feed item to the fresh aggregate (:109-113), queues the category (:115) and increments the count through a ref int parameter (:116). Note the asymmetry between the two paths: for an existing category items are reconciled against what is stored, while for a new one they are simply added, because there is nothing to reconcile against.

• Why it's built this way: a single bad row must not abort an import of hundreds, so the strategy degrades: warn, skip, keep going, and let the organizer read the warnings on the response. ignoreQueryFilters: true is required rather than optional here, because a feed id is the row's literal primary key: a soft-deleted category is invisible under the global filter, so without the flag the strategy would treat it as new and the insert would violate the primary key and roll the whole refresh back.

• Where it's used: instance zero of the handler's strategy array (RefreshFromSessionizeHandler.cs:31); its two counts become CategoriesSynced and CategoryItemsSynced on the response (RefreshFromSessionizeHandler.cs:146-147). Covered by MMCA.ADC/Tests/Modules/Conference/MMCA.ADC.Conference.Application.Tests/Events/UseCases/RefreshFromSessionize/CategorySyncStrategyTests.cs:15.

QuestionSyncStrategy

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Events.UseCases.RefreshFromSessionize · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Events/UseCases/RefreshFromSessionize/QuestionSyncStrategy.cs:12 · Level 10 · class (internal sealed)

• What it is: the step that upserts Question rows. It adds two concerns the category step does not have: deciding which entity a question belongs to, and refusing feed ids that would collide with organizer-created questions.
• Depends on: SessionizeSyncContext, SessionizeQuestion, Question, QuestionInvariants, and the repository from the context's unit of work.
• Concept: the four-phase shape is taught under CategorySyncStrategy. What is new here is the reserved identifier band. QuestionInvariants.ManualIdRangeStart and ManualIdRangeEnd are 999_999_000 and 999_999_999 (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Domain/Questions/QuestionInvariants.cs:40 and :43). Organizer-created questions take ids from that band; Sessionize allocates from far below it. A feed id landing inside the band would silently overwrite a question a human wrote, so the strategy filters those rows out with a warning before anything reaches the database (QuestionSyncStrategy.cs:30-41). [Rubric §8, Data Architecture] assesses how identity is allocated when rows arrive from two sources into one table: the split-range convention is what lets imported and hand-created questions share a key space without a mapping table.
• Walkthrough:
  • Answer-derived classification (:20-27): before touching the database, the strategy builds two hash sets, the question ids answered by speakers and the question ids answered by sessions, by flattening QuestionAnswers across the feed's speakers and sessions.
  • Reserved-id filter (:30-41): the guard above, producing validQuestions.
  • Bulk pre-load (:44-50): one GetByIdsAsync over the surviving ids with tracking on and query filters off, indexed by id.
  • Classification and mapping: DeriveQuestionEntity (:101-118) returns "Session" when a session answered the question, "Speaker" when a speaker did, and otherwise falls back to the stored value before defaulting to "Session" (:117). That ordering matters: a feed that happens to carry no answers this run offers no classification signal, so an existing question keeps its recorded entity instead of being reclassified. MapSessionizeQuestionType (:123-129) collapses the feed's open type vocabulary onto the three domain-valid values, passing "Rating" and "Email" through and mapping everything else (Short_Text, Long_Text, Url, YesNo) to "Text".
  • Update or create (:61-83): a soft-deleted match is skipped and counted (:63-67, BR-136); a live match is updated with existingQuestion.IsRequired passed back in (:69), so the organizer's required flag survives a re-sync. A new question is created with isRequired: false and questionSource: "Sessionize" (:73), which is how imported questions stay distinguishable from hand-created ones; a failed create warns and skips (:80-81).
  • Batch add and report (:88-93).
• Why it's built this way: classification cannot come from the feed's question record itself, only from which side of the payload answered it, which is why the two hash sets are computed up front rather than per row. Preserving IsRequired and the stored entity value on update is the same principle the room step applies to organizer-entered fields: the import owns the fields Sessionize sends and nothing else.
• Where it's used: instance two of the handler's array (RefreshFromSessionizeHandler.cs:33), reported as QuestionsSynced (RefreshFromSessionizeHandler.cs:149). MapSessionizeQuestionType is internal static so it can be exercised directly: the assembly grants InternalsVisibleTo to the application test project (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/MMCA.ADC.Conference.Application.csproj:3), and the tests live at MMCA.ADC/Tests/Modules/Conference/MMCA.ADC.Conference.Application.Tests/Events/UseCases/RefreshFromSessionize/QuestionSyncStrategyTests.cs:16.

RoomSyncStrategy

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Events.UseCases.RefreshFromSessionize · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Events/UseCases/RefreshFromSessionize/RoomSyncStrategy.cs:20 · Level 10 · class (internal sealed)

• What it is: the step that upserts Room rows. Rooms are children of the Event aggregate, so every mutation goes through the event, and this step carries the most defensive id handling of the five.
• Depends on: SessionizeSyncContext, SessionizeRoom, Event, Room, EventInvariants, Result, SessionizeSyncWarnings, and IReadRepository<TEntity, TIdentifierType>.
• Concept introduced, reading a child entity without granting it a write repository. Room is not an aggregate root, so the strategy resolves GetReadRepository<Room, RoomIdentifierType> (RoomSyncStrategy.cs:27) rather than a full repository: it may load and track the rows, but it cannot add or remove them directly. All writes route through context.Event (:109-122). [Rubric §4, DDD] assesses whether the aggregate root remains the only write entry point for its children, and that one line is the mechanical expression of the rule. [Rubric §11, Security] and [Rubric §8, Data Architecture] both bear on the id guards below: the strategy treats an external id as untrusted input that could point at another event's row or at an organizer-owned one.
• Walkthrough:
  • Reserved-band filter (:87-88 calling the predicate at :93-102): ExcludeReservedIds drops any feed room whose id falls between EventInvariants.RoomManualIdRangeStart and RoomManualIdRangeEnd, which are 999_999_000 and 999_999_999 (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Domain/Events/EventInvariants.cs:66 and :68), warning for each (:97). This mirrors the question-side guard exactly.
  • Unscoped id lookup (:43-49): one GetByIdsAsync with asTracking: true and ignoreQueryFilters: true, and deliberately not filtered by EventId. The reasoning is written into the file (:32-42): Sessionize allocates room ids from a global sequence, and a room id carries straight through as the row's primary key, so an id can already belong to another event's room. Filtering by event would hide that row, the strategy would treat the id as new, and the insert would hit the primary key and roll back the entire refresh across all five families. Loading it unscoped and skipping it keeps the damage at the single offending room.
  • Resolution order (:53-54): the aggregate's own Rooms collection is consulted first, and only if that misses does the strategy fall back to the unscoped dictionary.
  • Ownership guard (:59-63): if the row came only from the unscoped lookup and its EventId is not this event's, warn and skip. The comment records why the check is conditional (:56-58): anything already on the aggregate belongs to this event by construction, and a room added earlier in the same run still carries EventId 0 until EF assigns it on save.
  • Apply (:109-122): a three-way switch expression. No stored room means AddRoom (:112); a soft-deleted one means RestoreRoom (:113); otherwise UpdateRoom, which reads Capacity, Floor, Location and AccessibilityInfo back off the stored room (:118-121) because Sessionize never sends those. That is how organizer-entered room detail survives a re-sync.
  • Count acceptances only (:70-76): the aggregate can legitimately refuse a room (a name the feed repeats, a blank name). A refusal produces a warning and no increment, so the reported count and the warnings list always add up.
• Why it's built this way: the whole refresh is one transaction (ITransactional on RefreshFromSessionizeCommand), which makes any uncaught constraint violation an all-or-nothing loss. Each guard here converts a would-be transaction abort into a single skipped row plus a warning line. [Rubric §29, Resilience and Business Continuity] assesses whether a partial upstream defect degrades gracefully rather than taking the operation down.
• Where it's used: instance one of the handler's array (RefreshFromSessionizeHandler.cs:32), reported as RoomsSynced (RefreshFromSessionizeHandler.cs:148). Covered by MMCA.ADC/Tests/Modules/Conference/MMCA.ADC.Conference.Application.Tests/Events/UseCases/RefreshFromSessionize/RoomSyncStrategyTests.cs:11.

SessionSyncStrategy

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Events.UseCases.RefreshFromSessionize · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Events/UseCases/RefreshFromSessionize/SessionSyncStrategy.cs:14 · Level 10 · class (internal sealed)

• What it is: the last step of the import. It upserts Session rows and their three join collections (speakers, category items, question answers), and it runs last because a session references rooms, speakers and category items the earlier steps created.
• Depends on: SessionizeSyncContext, SessionizeSession, SessionizeQuestionAnswer, Session, SessionizeSyncWarnings, and the repository from the context's unit of work.
• Concept introduced, reactivate rather than re-add (BR-135). The session and its collections are loaded with ignoreQueryFilters: true (SessionSyncStrategy.cs:23-28), so the loaded SessionSpeakers, SessionCategoryItems and SessionQuestionAnswers collections carry the removed associations too. SyncSessionChildren (:117-159) uses that: for a feed association with no live match it first looks for a soft-deleted row with the same key and calls RestoreSessionSpeaker (:132) or RestoreSessionCategoryItem (:149), and only adds a new row when none exists (:136 and :153). Adding instead would leave the removed row in place and double the association. [Rubric §8, Data Architecture] assesses whether soft-delete is handled consistently on the write path as well as the read path: here the filters are turned off precisely so the write path can see and revive what the read path hides.
• Walkthrough:
  • Bulk pre-load (:23-29) with all three child collections included.
  • Advisory time validation (:53-71): ValidateSessionTimes warns when a session starts before the event's StartDate or ends after its EndDate (BR-86, :56-64) and when EndsAt is at or before StartsAt (BR-122, :67-70). None of these reject the session: the row is imported as-is and the organizer decides. [Rubric §24, Forms, Validation and UX Safety] assesses whether a system distinguishes a hard invariant from an advisory: schedule anomalies in a live conference feed are usually real and in flight, so blocking the import would be worse than reporting it.
  • Resolve or create (:73-115): a soft-deleted match is skipped and counted (:81-85, BR-136). A live match is updated with the feed's fields, while AccessibilityInfo and ResourceLinks are read back off the stored session (:93) because Sessionize does not send them. A miss goes to Session.Create (:97-103), which receives null for those same two fields and the event id from the context; a failed create warns and returns null (:104-110).
  • Children (:117-176): speakers and category items follow the restore-or-add shape above; SyncSessionQuestionAnswers (:161-176) updates the live answer for a question id if one exists and adds one otherwise, keyed on QuestionId with an IsDeleted guard (:165-166).
  • Batch add and report (:45-50).
• Why it's built this way: an import that runs repeatedly against a moving feed must be idempotent in the practical sense, that re-running it does not multiply rows. Keying every child comparison on the domain id plus an IsDeleted check, and preferring restore over insert, is what delivers that.
• Where it's used: instance four of the handler's array (RefreshFromSessionizeHandler.cs:35), reported as SessionsSynced (RefreshFromSessionizeHandler.cs:151). Covered by MMCA.ADC/Tests/Modules/Conference/MMCA.ADC.Conference.Application.Tests/Events/UseCases/RefreshFromSessionize/SessionSyncStrategyTests.cs:15.

SpeakerSyncStrategy

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Events.UseCases.RefreshFromSessionize · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Events/UseCases/RefreshFromSessionize/SpeakerSyncStrategy.cs:14 · Level 10 · class (internal sealed)

• What it is: the step that upserts Speaker rows, links each speaker to the event through EventSpeaker, and syncs each speaker's category items and question answers. It also turns the feed's loose link list into typed social fields.
• Depends on: SessionizeSyncContext, SessionizeSpeaker, SessionizeLink, SessionizeQuestionAnswer, Speaker, Event, EventSpeaker, SessionizeSyncWarnings, plus both IRepository<TEntity, TIdentifierType> and IReadRepository<TEntity, TIdentifierType>.
• Concept introduced, reviving an association the aggregate cannot see. The event was loaded by the handler with the global query filters on, so a removed EventSpeaker link is simply absent from context.Event.EventSpeakers. Re-adding it would create a second row alongside the removed one. LoadDeletedEventSpeakersAsync (:81-99) closes that hole: it opens a read repository for EventSpeaker (:85), queries this event's deleted links with ignoreQueryFilters: true and asTracking: true (:87-92), and groups them by speaker id, taking the first of each group because a speaker added and removed repeatedly can carry more than one removed link (:96-98). The link decision then reads: skip if a live link exists, restore a deleted one if either the aggregate or that dictionary has it, otherwise add (:48-61, BR-135). [Rubric §8, Data Architecture] assesses whether the soft-delete convention is applied coherently across an aggregate boundary, which is exactly the trap this method sidesteps.
• Walkthrough:
  • Bulk pre-load (:23-29) with SpeakerCategoryItems and SpeakerQuestionAnswers included, filters off, tracking on.
  • Social-link extraction (:183-215): ExtractSocialLinks walks the feed's links and matches LinkType case-insensitively, sending "Twitter" through ExtractTwitterHandle (:197-200), "LinkedIn" to the LinkedIn field (:201-204), "Blog" and "Company_Website" to the website field (:205-209), and falling back to a URL-content check for "github" (:210-213). ExtractTwitterHandle (:217-240) strips six known twitter.com and x.com prefixes, trims a leading @ and surrounding slashes, and returns null for an empty result. The #pragma warning disable S5332 around the replacement chain (:227-237) is deliberate and documented in place: the plain-http literals are input patterns being removed, not addresses this code connects to, and dropping them would leave legacy Sessionize profile links unparsed.
  • Create or update (:101-143): a soft-deleted speaker is skipped and counted (:113-117). A live one is updated with existingSpeaker.Email?.Value passed back in (:120) so the stored email survives, since the feed does not carry it. A new speaker goes through Speaker.Create with a null email (:126) and is then immediately updated (:137-140) because the factory does not accept the social fields; a failed create warns and returns null (:127-133).
  • Children (:145-181): SyncCategoryItems (:145-164) uses the restore-or-add shape; SyncQuestionAnswers (:166-181) updates a live answer by its id or adds a new one.
  • Batch add and report (:67-72).
• Why it's built this way: the module treats Sessionize as the owner of the fields Sessionize sends and the organizer as the owner of everything else, so every update call in this file threads the locally held values (email here, room detail in the room step, IsRequired in the question step) back through the aggregate rather than blanking them. [Rubric §30, Compliance, Privacy and Data Governance] assesses whether personal data is written only from the source entitled to set it: the speaker email is never overwritten by an import.
• Where it's used: instance three of the handler's array (RefreshFromSessionizeHandler.cs:34), reported as SpeakersSynced (RefreshFromSessionizeHandler.cs:150). Covered by MMCA.ADC/Tests/Modules/Conference/MMCA.ADC.Conference.Application.Tests/Events/UseCases/RefreshFromSessionize/SpeakerSyncStrategyTests.cs:12.

GetPublicRoomFilterHandler

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Events.UseCases.GetPublicRoomFilter · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Events/UseCases/GetPublicRoomFilter/GetPublicRoomFilterHandler.cs:16 · Level 11 · class (sealed)

• What it is: the handler for GetPublicRoomFilterQuery. It asks PublicConferenceVisibility for the published event ids and returns a Room.EventId IN (...) specification. It is the simplest member of the public-filter family: one resolver call, one predicate, no failure path.
• Depends on: IUnitOfWork (:17, injected only to hand on to the resolver), PublicConferenceVisibility, InlineSpecification<TEntity, TIdentifierType> and its base Specification<TEntity, TIdentifierType>, Room, and Result. It implements IQueryHandler<in TQuery, TResult> to Result<Specification<Room, RoomIdentifierType>> (:18).
• Concept: the query-that-returns-a-specification shape is taught under GetPublicSessionFilterHandler: a handler whose result is a reusable predicate rather than data, so the visibility rule is resolved once in the Application layer and applied by whichever read the controller is serving. [Rubric §6, CQRS and Event-Driven] assesses whether reads are expressed as explicit, single-purpose query objects; this is a query whose payload is the filter itself. [Rubric §11, Security] assesses the anonymous read surface: the rule here is one line of predicate, and it is the only thing standing between an unpublished event's venue layout and an anonymous caller.
• Walkthrough:
  1. HandleAsync (:21-23) takes the marker query and a CancellationToken.
  2. Resolve the published event ids: PublicConferenceVisibility.GetPublishedEventIdsAsync(unitOfWork, cancellationToken) (:25-27). Inside the shared resolver that is a scalar, untracked projection of Event.Id where IsPublished, materialized once so the list embedded in the predicate is stable and EF-translatable to IN (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Common/PublicConferenceVisibility.cs:36-47).
  3. Wrap r => publishedEventIds.Contains(r.EventId) in an InlineSpecification<TEntity, TIdentifierType> and return Result.Success (:29-30). Nothing here can fail, so Result is used for pipeline uniformity rather than to carry an error.
• Why it's built this way: the summary (:10-15) says the id-list shape mirrors the sponsor, speaker, and session public filters, so no navigation join is required and the criteria stays translatable on any engine (ADR-018). Room is the easy case for that rule because it carries a real EventId column (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Domain/Events/Room.cs:38), so the parent's visibility is expressible directly on the child's own column, with no traversal and no join table. Sourcing the id list from the shared PublicConferenceVisibility rather than restating IsPublished here is what keeps one definition of "published" behind every public read.
• Where it's used: RoomsController injects it as an IQueryHandler (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.API/Controllers/Events/RoomsController.cs:97) and calls it from its GetReadSpecificationAsync override (RoomsController.cs:120-130), which short-circuits to null when IsPrivileged (:123-124, backed by currentUserService.IsPrivilegedConferenceReader() at :104), so Organizer and ContentEditor readers see every room. GetReadSpecificationAsync is the framework's read hook declared on EntityControllerBase<TEntity, TEntityDTO, TIdentifierType> (MMCA.Common/Source/Presentation/MMCA.Common.API/Controllers/EntityControllerBase.cs:597) and consumed by every base read action (EntityControllerBase.cs:115, :170, :264, :378, :422), so overriding it once scopes all four of the controller's [AllowAnonymous] reads at a stroke: the unpaged list (RoomsController.cs:136-144), the paged list (:152-165), the lookup (:173-179) and the by-id read (:186-195). Those four actions are attribute-only passthroughs whose bodies delegate straight to base; each also carries [OutputCache(PolicyName = "RoomsCache")] (:138, :154, :175, :188), and the three write actions evict the conference:rooms output-cache tag afterwards (:225, :254, :272).
• Testing: there is no per-handler unit-test class for this filter; it is covered from the controller side by RoomsControllerTests (MMCA.ADC/Tests/Modules/Conference/MMCA.ADC.Conference.API.Tests/Controllers/Events/RoomsControllerTests.cs:26), which mocks the handler (:32) and asserts the paired behavior on all four reads: the specification is applied for an anonymous or Attendee caller and never resolved for an Organizer or ContentEditor one (:199 and :214 unpaged, :229 and :245 paged, :261 and :277 lookup, :292 and :312 by-id). SetupPublicRoomFilter stands in a filter of its own, r => r.EventId == 1 (:329-333), and VerifyFilterNeverResolved (:335-338) is what proves the privileged path never even calls the handler. [Rubric §14, Testability]: the branch worth protecting is the privileged short-circuit, because a regression there is silent (privileged callers would simply see less), and these are the tests that would catch it.
• Caveats / not-in-source: the override maps a failed Result to null, that is, to no filter at all (RoomsController.cs:129), the same fail-open shape noted on GetPublicEventSpeakerFilterHandler. No path in this handler produces a failure today. The published-event id list is also materialized into the predicate, so the IN list grows with the number of published events; PublicConferenceVisibility describes that table as bounded at single-digit rows, but nothing in code enforces that bound.

RefreshFromSessionizeHandler

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Events.UseCases.RefreshFromSessionize · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Events/UseCases/RefreshFromSessionize/RefreshFromSessionizeHandler.cs:20 · Level 14 · class (sealed partial)

• What it is: the command handler behind UC-6. It checks the preconditions, calls the Sessionize API, runs the five strategies in dependency order against one shared context, stamps the refresh on the event, saves everything in one transaction, and returns the per-entity counts and warnings.

• Depends on: IUnitOfWork, ISessionizeService, ICurrentUserService, TimeProvider (BCL), ILogger<T> (Microsoft.Extensions.Logging), Event, Result and Error, RefreshFromSessionizeCommand, RefreshFromSessionizeResultDTO, SessionizeResponse, SessionizeSyncContext, SessionizeSyncResult, ISessionizeSyncStrategy and its five implementations. Externals: Polly.CircuitBreaker and Polly.Timeout (for the two rejection types it catches) and System.Text.Json.

• Concept introduced, classifying an upstream failure instead of letting it become a 500. IsSessionizeUnavailable (RefreshFromSessionizeHandler.cs:167-172) treats five exception types as "no usable Sessionize data right now": HttpRequestException, Polly's TimeoutRejectedException and BrokenCircuitException, and JsonException or NotSupportedException. The last two matter because an upstream that serves an HTML error page with a success status makes the JSON read fail on content rather than on transport. The Polly types appear because the client runs behind the standard resilience pipeline from AddServiceDefaults, so an unreachable API often reaches the handler as a pipeline rejection rather than a socket error. Critically, the catch block re-checks cancellation first (:86): a broadened catch must not convert a caller's cancellation into an "upstream is down" answer. [Rubric §13, Observability and Operability] assesses whether operators can tell a dependency outage from a defect: this classification is what lets the controller answer 502 instead of 500. [Rubric §29, Resilience and Business Continuity] assesses graceful degradation against a third-party dependency.

• Walkthrough:

  • Static strategy array (:28-35): five stateless instances in dependency order (categories, rooms, questions, speakers, sessions), with the ordering rationale in the comment above them (:26-27). static readonly because the strategies hold no state; all state lives in the per-command context.
  • Primary constructor (:19-24): five dependencies. sealed partial is what allows the [LoggerMessage] source-generated log method at the bottom of the file (:173-174).
  • Load the aggregate (:43-54): GetByIdAsync with Rooms and EventSpeakers included and asTracking: true, returning Error.NotFound when the event is missing.
  • Precondition, a configured code (:57-64, BR-6): a blank SessionizeCode fails with Event.Sessionize.NoCode.
  • Precondition, the throttle (:67-75, BR-63): if LastSessionizeRefreshOn is less than five minutes before timeProvider.GetUtcNow(), the handler fails with Event.Sessionize.Throttled and never calls the API. Time comes from an injected TimeProvider, which is what makes the window testable without waiting.
  • Call the API (:78-93), with the classification above.
  • An empty response is success (:96-111): a null response is not an error, since an event may have no data yet. The handler stamps the refresh, saves, and returns a DTO of zeros with no warnings.
  • Run the strategies (:114-126): one context is built and the five SyncAsync calls run sequentially, collecting a SessionizeSyncResult each.
  • Summarize skips (:128-131): a non-zero SkippedSoftDeleted becomes one final warning line naming the count and BR-136.
  • Stamp and save (:134-139): RecordSessionizeRefresh writes the current user id and timestamp onto the aggregate, then unitOfWork.RequestIdentityInsert() (:138) is called before the single SaveChangesAsync (:139). This is the load-bearing detail of the whole use case: Sessionize rows keep their external ids as primary keys in tables whose key columns are IDENTITY, so the unit of work has to wrap the save in SET IDENTITY_INSERT ON/OFF per table. The request flag is declared on IUnitOfWork (MMCA.Common/Source/Core/MMCA.Common.Application/Interfaces/Infrastructure/Persistence/IUnitOfWork.cs:49), forwarded to the context factory (MMCA.Common/Source/Core/MMCA.Common.Infrastructure/Persistence/UnitOfWork.cs:76), read and reset on the next save (MMCA.Common/Source/Core/MMCA.Common.Infrastructure/Persistence/DbContexts/Factory/DbContextFactory.cs:228-229), and routed to the per-table round-splitting path for SQL Server contexts (DbContextFactory.cs:248-250, implemented at DbContextFactory.cs:285).
  • Log and project (:141-153): the source-generated information-level log records the event id, then the five results are read positionally, results[0] through results[4], into the response DTO.

  [Rubric §6, CQRS and Event-Driven] assesses whether writes flow through one explicit handler boundary: this type implements ICommandHandler<in TCommand, TResult> (:24), is wrapped by the decorator pipeline described in group 5, and the controller knows only the interface. [Rubric §3, Clean Architecture] assesses dependency direction: the handler names ISessionizeService, never an HTTP client, so the outbound call is an abstraction the infrastructure layer satisfies with SessionizeService.

• Why it's built this way: one transaction across five entity families is not an optimization, it is what keeps sessions from referencing rooms or speakers that did not commit. That constraint drives the rest of the design: strategies must not throw on a bad row (a throw would abort everything), they must not provoke primary key collisions (hence the unscoped lookups and the reserved-band guards), and the handler must not save between steps.

• Where it's used: injected into EventsController as ICommandHandler<RefreshFromSessionizeCommand, Result<RefreshFromSessionizeResultDTO>> (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.API/Controllers/Events/EventsController.cs:54) and invoked from RefreshAsync (EventsController.cs:329-334), which is [HttpPost("{id}/refresh")] and [Idempotent] (EventsController.cs:327-328). The controller maps the two well-known error codes onto transport: Event.Sessionize.Throttled becomes a 429 with a Retry-After of 300 seconds (EventsController.cs:340-343) and Event.Sessionize.Unavailable becomes a 502 (EventsController.cs:347-348). Unit tests live at MMCA.ADC/Tests/Modules/Conference/MMCA.ADC.Conference.Application.Tests/Events/UseCases/RefreshFromSessionize/RefreshFromSessionizeHandlerTests.cs:16, with an integration tier at MMCA.ADC/Tests/Integration/MMCA.ADC.Conference.IntegrationTests/Organizer/SessionizeRefreshTests.cs.

• Caveats: the DTO projection is positional (:145-150), so the response mapping is coupled to the order of the static array; inserting a sixth strategy anywhere but the end would silently shift every count that follows it. Both RecordSessionizeRefresh calls dereference currentUserService.UserId!.Value (:98 and :134) with the null-forgiving operator, so the handler assumes an authenticated caller and would throw for an anonymous one; the endpoint's authorization is what upholds that assumption.

EventDateRangeRules<T>

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Events.Validation · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Events/Validation/EventValidationRules.cs:113 · Level 0 · class (sealed, generic)

• What it is: a reusable FluentValidation rule fragment that enforces event date-range integrity: a start date is required, an end date is required, and the end date must fall on or after the start date. It is the only fragment in the Events validation folder that reasons about two properties at once.
• Depends on: FluentValidation's AbstractValidator<T> (NuGet, primer §3) and System.Linq.Expressions.Expression<> (BCL). No first-party types: the file's MMCA.ADC.Conference.Domain.Events and MMCA.Common.Application.Validation imports (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Events/Validation/EventValidationRules.cs:3-4) serve its sibling fragments in the same file, not this one.
• Concept, the cross-field rule fragment. The module-local fragment idiom itself is taught on ActivityEventIdRules<T>, and the framework fragments it composes over live in group-06. What this class adds is the two-property case. A single-field fragment closes over one Expression<Func<T, TProp>>; a cross-field fragment takes two selectors and must read one property while validating the other. FluentValidation's two-argument Must overload is the mechanism: the predicate receives both the instance under validation and the value of the property the rule is attached to, so the sibling property is reachable through a compiled getter. [Rubric §1, SOLID] assesses single responsibility and open/closed adherence: "end after start" is its own fragment rather than a clause bolted onto a name or time-zone rule, so adding a constraint means composing another Include(...) line, never editing an existing fragment. [Rubric §24, Forms, Validation & UX Safety] assesses whether validation is centralized and machine-addressable: one fragment serves both the create and the update path through EventFieldRules<T>, and each of its three rules carries a stable dotted error code beside its human message.
• Walkthrough: the constructor (EventValidationRules.cs:116-118) takes two Expression<Func<T, DateOnly>> selectors, startDateSelector and endDateSelector. It registers NotEmpty on each, with the distinct codes Event.StartDate.Required (:120-121) and Event.EndDate.Required (:123-124). The cross-field check is the part worth reading closely: the start-date selector is compiled to a delegate once, at construction (var startDateFunc = startDateSelector.Compile();, :126), and a second rule on the end date calls Must((instance, endDate) => endDate >= startDateFunc(instance)) with the message "End Date must be on or after the Start Date" and the code Event.EndDate.BeforeStart (:127-129). Because the delegate is captured in the constructor, the expression tree is compiled per validator instance, not per validated request.
• Why it's built this way: the same rule exists on the domain side as EventInvariants.EnsureDateRangeIsValid (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Domain/Events/EventInvariants.cs:112-119, delegating to CommonInvariants.EnsureEndIsNotBeforeStart under the code Event.DateRange.Invalid), so the fragment is not the only guard: it is the fast, field-attributed one that fires before a handler or an aggregate is touched, while the invariant is the backstop for any caller that bypasses the validator. Splitting the concern into its own fragment is what lets the shared rule set pull in exactly this rule instead of inheriting a monolithic event validator.
• Where it's used: Included by EventFieldRules<T> as new EventDateRangeRules<T>(p => p.StartDate, p => p.EndDate) (EventValidationRules.cs:147), which is itself included by EventCreateRequestValidator and EventUpdateRequestValidator. The end-before-start case is pinned by EventCreateRequestValidatorTests.Validate_WithEndDateBeforeStartDate_ReturnsError (MMCA.ADC/Tests/Modules/Conference/MMCA.ADC.Conference.Application.Tests/Events/Validation/EventCreateRequestValidatorTests.cs:55).
• Caveats / not-in-source: NotEmpty on a DateOnly rejects default(DateOnly) (January 1, year 1), so a caller that never sets a date fails the required rule. That is FluentValidation's default-value semantics, not something this fragment states.

IEventFieldsRequest

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Events.Validation · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Events/Validation/IEventFieldsRequest.cs:12 · Level 0 · interface

• What it is: the seven-member shape describing exactly the event fields that the create request and the update request validate identically. It exists so one rule set can be declared once over the shape instead of twice over two concrete records.
• Depends on: nothing. It has no base interface, no attributes, and no imports at all: the file opens straight into the namespace declaration (IEventFieldsRequest.cs:1). DateOnly is BCL.
• Concept, the validation-shaped interface. Most interfaces in this codebase describe a capability (a handler, a repository, a module). This one describes a field set, and its only purpose is to be a generic constraint. Two request records (EventCreateRequest and EventUpdateRequest) carry more properties than these seven, but the seven are the ones both operations validate the same way. Declaring them as an interface lets EventFieldRules<T> write where T : IEventFieldsRequest and then reach the properties through lambdas (p => p.Name) that bind at the interface, not at either record. [Rubric §1, SOLID] assesses interface segregation and dependency inversion: the interface is exactly as wide as the rule set that consumes it, and the rule set depends on the abstraction rather than on either concrete request. [Rubric §9, API & Contract Design] assesses whether a contract states what it guarantees: every member here is get-only, so the interface promises readability of a field, never mutation of one.
• Walkthrough: seven get-only members, each with its own doc comment. Name (:15) and TimeZone (:24) are non-nullable string; StartDate (:18) and EndDate (:21) are DateOnly; OrganizerContactEmail (:27), SponsorshipPacketUrl (:30), and TicketingUrl (:33) are nullable string?, matching the three optional fields whose fragments guard on presence. The type's <remarks> block (:8-11) names the deliberate omission: the live-layer moderation default is not on the interface, because only the update request carries it and its rule lives in that operation's own validator.
• Why it's built this way: without the interface, the shared rules would have to be written twice (once per record) or the rule set would have to be non-generic and duplicated. The interface is the smallest thing that removes the duplication, and its remarks make the per-operation delta explicit rather than leaving a reader to wonder why the moderation default is missing: EventUpdateRequestValidator adds RuleFor(x => x.QuestionModerationDefault).IsInEnum() under the code Event.QuestionModerationDefault.Invalid after including the shared set (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Events/UseCases/Update/EventUpdateRequestValidator.cs:13-18).
• Where it's used: as the generic constraint on EventFieldRules<T> (EventValidationRules.cs:141), and implemented by EventCreateRequest (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Events/UseCases/Create/EventCreateRequest.cs:11, alongside ICreateRequest and ICacheInvalidating) and EventUpdateRequest (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Events/UseCases/Update/EventUpdateRequest.cs:7).
• Caveats / not-in-source: the interface lives in the Events.Validation namespace, not beside the requests, so both request files take a using MMCA.ADC.Conference.Application.Events.Validation; to implement it (EventCreateRequest.cs:1, EventUpdateRequest.cs:1). Nothing enforces that a future event request implements it: a third request could re-declare the same seven fields and silently miss the shared rule set.

RoomCapacityRules<T>

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Events.Validation · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Events/Validation/RoomValidationRules.cs:37 · Level 0 · class (sealed, generic)

• What it is: a reusable rule fragment enforcing that a room's capacity, when supplied, is strictly positive. Capacity is optional (int?), so the rule only fires when a value is present.
• Depends on: FluentValidation's AbstractValidator<T> and System.Linq.Expressions.Expression<>. No first-party types: unlike the string fragments in the same file it reads no domain constant.
• Concept: the module-local rule fragment taught on ActivityEventIdRules<T>. The wrinkle worth noticing here is the conditional: .When(x => selector.Compile()(x) is not null) (RoomValidationRules.cs:43) guards the GreaterThan(0) rule (:42) so a null capacity is silently accepted rather than reported as invalid. [Rubric §24, Forms, Validation & UX Safety] assesses whether validation matches a field's real optionality: an absent optional numeric field should not raise an error, while a present but nonsensical one should.
• Walkthrough: the constructor takes an Expression<Func<T, int?>> selector (:40), chains GreaterThan(0) with the message "Capacity must be greater than 0" and the error code Room.Capacity.NotPositive (:41-42), then applies the null-guard When clause (:43).
• Why it's built this way: separating the presence check (When) from the value check keeps the "optional but bounded" semantics in one place: a room without a known capacity is valid, a room claiming a non-positive capacity is not. The domain states the same rule as EventInvariants.EnsureRoomCapacityIsValid, which delegates to CommonInvariants.EnsureNullableIntIsPositive under the code Room.Capacity.Invalid (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Domain/Events/EventInvariants.cs:127-132), tagged BR-93 in its doc comment (:121), so the fragment and the invariant agree on treating null as acceptable.
• Where it's used: Included by AddRoomCommandValidator (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Events/UseCases/AddRoom/AddRoomCommandValidator.cs:13) and UpdateRoomCommandValidator (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Events/UseCases/UpdateRoom/UpdateRoomCommandValidator.cs:13), both on p => p.Capacity. Both branches are pinned by AddRoomCommandValidatorTests (MMCA.ADC/Tests/Modules/Conference/MMCA.ADC.Conference.Application.Tests/Events/Validation/CommandValidatorTests.cs:100, :108).
• Caveats / not-in-source: unlike EventDateRangeRules<T>, which compiles its selector once at construction, the When predicate here calls selector.Compile() inside the lambda (:43), so the expression is recompiled on each evaluation rather than cached.

RoomSortRules<T>

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Events.Validation · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Events/Validation/RoomValidationRules.cs:26 · Level 1 · class (sealed, generic)

• What it is: a reusable rule fragment enforcing that a room's sort-order value is non-negative. It is two lines long, because it inherits the whole rule from a framework base and supplies only the field label and the error code.
• Depends on: NonNegativeIntRules<T>, its base class from the framework (MMCA.Common/Source/Core/MMCA.Common.Application/Validation/CommonValidationRules.cs:122), plus System.Linq.Expressions.Expression<> (BCL). No domain constant.
• Concept, subclassing a framework fragment while keeping the module's error code. The framework base takes an optional errorCode parameter (CommonValidationRules.cs:124) and applies it to every rule it declares through the internal WithOptionalErrorCode helper (:30-32), which returns the rule untouched when the code is null. That parameter is why a module fragment can inherit the base and still hand clients a stable machine-readable code, which is the trade the hand-written fragments in this module otherwise have to make by writing the rule chain out. [Rubric §9, API & Contract Design] assesses the stability of the error contract clients consume: Room.Sort.Negative travels with the message rather than the message having to be parsed. [Rubric §15, Best Practices & Code Quality] assesses whether a constraint lives in exactly one place: the comparison itself is written once in the framework, and the module supplies only the naming.
• Walkthrough: the class declares : NonNegativeIntRules<T> (RoomValidationRules.cs:27) and its constructor takes an Expression<Func<T, int>> selector, forwarding base(selector, "Sort", "Room.Sort.Negative") (:29-30). The base registers a single GreaterThanOrEqualTo(0) rule with the message "Sort must be greater than or equal to 0" and attaches the supplied code (CommonValidationRules.cs:124-126).
• Why it's built this way: GreaterThanOrEqualTo(0) rather than GreaterThan(0) because zero is a legitimate "first in the list" position, which is why the framework's PositiveIntRules<T> (CommonValidationRules.cs:100-105) is the wrong base to reuse here. Sort order drives deterministic room ordering in the UI, so a negative value is rejected at the application boundary.
• Where it's used: Included by AddRoomCommandValidator (AddRoomCommandValidator.cs:12) and UpdateRoomCommandValidator (UpdateRoomCommandValidator.cs:12), both on p => p.Sort, alongside RoomCapacityRules<T>. Both validators have a negative-sort test (CommandValidatorTests.cs:92, :137).
• Caveats / not-in-source: nothing in EventInvariants mirrors this rule, so unlike room name and room capacity the sort order has no domain-side backstop: this fragment is the only guard on the path.

EventNameRules<T>

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Events.Validation · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Events/Validation/EventValidationRules.cs:13 · Level 7 · class (sealed, generic)

• What it is: a reusable rule fragment for the event name: non-empty and bounded by EventInvariants.NameMaxLength, which resolves to EventDTO.NameMaxLength, 500 characters (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Domain/Events/EventInvariants.cs:17, MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Shared/Events/EventDTO.cs:19).
• Depends on: RequiredStringRules<T>, its base class from the framework (MMCA.Common/Source/Core/MMCA.Common.Application/Validation/CommonValidationRules.cs:41), and EventInvariants for the bound, which in turn re-exports the constant from EventDTO.
• Concept: the same fragment idiom taught on ActivityEventIdRules<T>, but taken to its terse extreme: instead of writing a rule chain, this fragment subclasses the framework's shared RequiredStringRules<T> and passes it a field label and a bound, delegating the NotEmpty plus MaximumLength wiring to the base (CommonValidationRules.cs:43-46). [Rubric §4, DDD] assesses ubiquitous language in code: the class is named EventNameRules after the domain field, not a generic "NameValidator". [Rubric §15, Best Practices & Code Quality] assesses reuse across repos: the module writes two lines, because the shared base owns the message shape and the length constant lives once in the domain.
• Walkthrough: one constructor taking an Expression<Func<T, string>> selector (:16), whose entire body is the base call base(selector, "Event Name", EventInvariants.NameMaxLength) (:17). The base produces the two messages "You must enter a Event Name" and "Event Name cannot be longer than 500 characters" (CommonValidationRules.cs:44-46).
• Why it's built this way: the length constant is the same value the domain-side invariant enforces (EventInvariants.EnsureNameIsValid, EventInvariants.cs:71-74, error codes Event.Name.Empty and Event.Name.TooLong) and the same one the EF configuration and the form field use, so the validation message, the aggregate guard, and the schema cannot drift apart.
• Where it's used: Included by EventFieldRules<T> on p => p.Name (EventValidationRules.cs:145), which reaches both EventCreateRequestValidator and EventUpdateRequestValidator. The empty-name case is pinned at EventCreateRequestValidatorTests.cs:33.
• Caveats / not-in-source: this fragment passes no errorCode to the base, even though the base accepts one (CommonValidationRules.cs:43), so the event name yields a human message with no machine-readable code, unlike RoomNameRules<T> or RoomSortRules<T>. The base message also reads "You must enter a Event Name", an article-agreement artifact of building the message from the field label.

EventOrganizerContactEmailRules<T>

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Events.Validation · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Events/Validation/EventValidationRules.cs:57 · Level 7 · class (sealed, generic)

• What it is: a rule fragment for the event's optional organizer contact email. When the caller supplies a value it must be a well-formed email address no longer than EventInvariants.OrganizerContactEmailMaxLength, 255 characters (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Domain/Events/EventInvariants.cs:38, MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Shared/Events/EventDTO.cs:40); when the caller leaves it blank, no rule runs at all.
• Depends on: EmailRules<T>, the shared framework fragment it wraps (MMCA.Common/Source/Core/MMCA.Common.Application/Validation/CommonValidationRules.cs:64-70), and EventInvariants. It inherits AbstractValidator<T> directly and uses System.Linq.Expressions.Expression<>.
• Concept, conditional inclusion of a required-field fragment. The fragments seen so far either always apply (EventNameRules<T>) or are unconditionally length-only (RoomFloorRules<T>). This one is different: the shared EmailRules<T> it wants to reuse starts with NotEmpty (CommonValidationRules.cs:67), which is exactly wrong for an optional field. Rather than fork a near-copy of the shared fragment, the constructor compiles the selector once (var accessor = selector.Compile();, EventValidationRules.cs:62) and wraps the whole Include in FluentValidation's When(...), so the required-email rules are only registered against instances that actually carry a value (:64-65). [Rubric §1, SOLID] assesses open/closed adherence: optionality is composed around the shared rule, never by modifying it. [Rubric §24, Forms, Validation & UX Safety] assesses whether validation matches the field's real optionality: an organizer who never fills the field sees no error, while a typo in a filled field is still rejected as a bad address.
• Walkthrough: the constructor takes an Expression<Func<T, string>> selector (:60), compiles it to a delegate (:62), then calls When(x => !string.IsNullOrWhiteSpace(accessor(x)), () => Include(new EmailRules<T>(selector, "Organizer Contact Email", EventInvariants.OrganizerContactEmailMaxLength))) (:64-65). Inside the guard the shared base contributes three chained rules: NotEmpty, EmailAddress, and MaximumLength, all with messages built from the "Organizer Contact Email" field label (CommonValidationRules.cs:66-69).
• Why it's built this way: the field's doc comment states the product reason (:51-55): the value is optional, and an empty value means the public page falls back to the configured support address rather than showing nothing. That fallback is real. PublicEventDetail seeds _supportEmail from Configuration["Support:Email"] (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Pages/Public/Events/PublicEventDetail.razor.cs:43, :56) and, once the event loads, keeps the configured address when Event.OrganizerContactEmail is blank and uses the event's own address otherwise (:142-144). Rejecting a blank value at the boundary would break that intended default.
• Where it's used: Included by EventFieldRules<T> as p => p.OrganizerContactEmail! (EventValidationRules.cs:148), so it reaches both EventCreateRequestValidator and EventUpdateRequestValidator. Blank, valid, malformed, and overlong cases each have a test (EventCreateRequestValidatorTests.cs:83, :93, :103, :113).
• Caveats / not-in-source: the selector type is non-nullable string while the underlying interface member is string? (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Events/Validation/IEventFieldsRequest.cs:27), which is why the call site passes the null-forgiving p => p.OrganizerContactEmail!. The ! only silences the compiler; the runtime null is handled by the When guard, and that combination is what makes it safe. There is also no domain-side invariant for this field: EventInvariants defines the length constant (:37) and the EF configuration applies it to the column (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Infrastructure/Persistence/EntityConfiguration/Events/EventConfiguration.cs:60-62), but no Ensure... method validates the address, so this fragment is the only format check on the path.

EventSponsorshipPacketUrlRules<T>

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Events.Validation · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Events/Validation/EventValidationRules.cs:77 · Level 7 · class (sealed, generic)

• What it is: a rule fragment for the event's optional sponsorship-packet URL. When a value is supplied it must be no longer than EventInvariants.SponsorshipPacketUrlMaxLength, 2000 characters (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Domain/Events/EventInvariants.cs:41, MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Shared/Events/EventDTO.cs:43), and an absolute http or https URL.
• Depends on: AbsoluteUrlRules<T>, the shared framework fragment it wraps (MMCA.Common/Source/Core/MMCA.Common.Application/Validation/CommonValidationRules.cs:85-92), and EventInvariants. It inherits AbstractValidator<T> directly. Transitively it depends on CommonInvariants, because the framework fragment delegates its scheme predicate to CommonInvariants.EnsureUrlIsWellFormed (CommonValidationRules.cs:91-92).
• Concept, the scheme check as a rendering-safety rule. Structurally this is the same conditional-inclusion shape taught on EventOrganizerContactEmailRules<T>: compile the selector once, then Include a shared fragment inside a When guard. What it adds is which fragment it wraps. A length-only bound accepts javascript:alert(1) and data:application/pdf;base64,..., and those values become executable the moment a link or an image renders them; the shared fragment's remarks say exactly that (CommonValidationRules.cs:76-83). AbsoluteUrlRules<T> therefore adds Must(BeAnAbsoluteHttpUrl) on top of the same MaximumLength, and the predicate resolves through CommonInvariants.EnsureUrlIsWellFormed (MMCA.Common/Source/Core/MMCA.Common.Domain/Invariants/CommonInvariants.cs:293-297), whose private IsAbsoluteHttpUrl requires Uri.TryCreate(url, UriKind.Absolute, ...) to succeed with an ordinal scheme match against http or https (:436-439). [Rubric §11, Security] assesses whether untrusted input is constrained before it reaches a rendering surface: the string is validated as a string, deliberately, before anything turns it into a Uri (the suppression justification at CommonInvariants.cs:289-292 spells that reasoning out). [Rubric §26, Front-End Security] assesses the same question from the browser's side: the value ends up in an Href, so a non-http scheme reaching persistence would be a stored script vector.
• Walkthrough: the constructor takes an Expression<Func<T, string?>> selector (:80), note the nullable string? here as against the non-nullable selector of its email sibling, compiles it (:82), and registers When(x => !string.IsNullOrWhiteSpace(accessor(x)), () => Include(new AbsoluteUrlRules<T>(selector, "Sponsorship Packet URL", EventInvariants.SponsorshipPacketUrlMaxLength))) (:84-85). The shared base contributes two rules: MaximumLength with the message "Sponsorship Packet URL cannot be longer than 2000 characters", then Must(BeAnAbsoluteHttpUrl) with the message "Sponsorship Packet URL must be an absolute http or https URL" (CommonValidationRules.cs:87-89).
• Why it's built this way: the doc comment gives both reasons (:69-75). The product reason is that the field is optional, and an empty value means the landing page and the public sponsor page hide the sponsorship call to action rather than rendering a dead link: PublicSponsorList renders its download button only when the URL is non-blank (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Pages/Public/PublicSponsorList.razor:29, :36, with the value loaded at PublicSponsorList.razor.cs:63) and the landing page guards its own call to action the same way (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Pages/Home/ADCHome.razor:315, :327). The safety reason is the scheme check described above. Wrapping the shared fragment rather than re-declaring the rules keeps the validator and the framework's URL invariant answering identically.
• Where it's used: Included by EventFieldRules<T> on p => p.SponsorshipPacketUrl (EventValidationRules.cs:149), reaching both EventCreateRequestValidator and EventUpdateRequestValidator. The scheme rule is pinned by a theory that feeds it a scheme-less host and a data: payload (EventCreateRequestValidatorTests.cs:218-221), and the optional and overlong cases at :130 and :153.
• Caveats / not-in-source: the wrapped base sets no WithErrorCode because this fragment passes none (CommonValidationRules.cs:87), so a client keying off error codes gets nothing for this field. Neither is there a domain-side backstop: no Ensure... method in the Conference module calls EnsureUrlIsWellFormed, so a caller that bypasses the validator can still persist a non-http value within the length bound, subject only to the EF column length (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Infrastructure/Persistence/EntityConfiguration/Events/EventConfiguration.cs:65-66).

EventTicketingUrlRules<T>

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Events.Validation · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Events/Validation/EventValidationRules.cs:97 · Level 7 · class (sealed, generic)

• What it is: a rule fragment for the event's optional ticketing URL, bounded to EventInvariants.TicketingUrlMaxLength, 2000 characters (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Domain/Events/EventInvariants.cs:44, MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Shared/Events/EventDTO.cs:46) and required to be an absolute http or https URL when supplied. It is the exact twin of its sponsorship sibling, one field over.
• Depends on: AbsoluteUrlRules<T> (MMCA.Common/Source/Core/MMCA.Common.Application/Validation/CommonValidationRules.cs:85-92) and EventInvariants. It inherits AbstractValidator<T> directly.
• Concept: the conditional-inclusion shape taught on EventOrganizerContactEmailRules<T> and the scheme check taught on EventSponsorshipPacketUrlRules<T>, repeated verbatim. Reading the three optional event fragments in a row (:57, :77, :97) is the clearest illustration of the module's convention: an optional field gets a compiled accessor, a When presence guard, and an Include of a shared framework fragment, and the only things that vary between them are which framework fragment is wrapped and which invariant constant bounds it. [Rubric §2, Design Patterns] assesses whether a recurring shape is expressed as a reusable composition rather than duplicated logic: the wrapping is identical, only the parameters change.
• Walkthrough: the constructor takes an Expression<Func<T, string?>> selector (:100), compiles it to a delegate (:102), and registers When(x => !string.IsNullOrWhiteSpace(accessor(x)), () => Include(new AbsoluteUrlRules<T>(selector, "Ticketing URL", EventInvariants.TicketingUrlMaxLength))) (:104-105). The shared base contributes the MaximumLength rule whose message is "Ticketing URL cannot be longer than 2000 characters" and the Must(BeAnAbsoluteHttpUrl) rule whose message is "Ticketing URL must be an absolute http or https URL" (CommonValidationRules.cs:87-89).
• Why it's built this way: the doc comment states the product reason (:89-95): the field is optional, and an empty value means the landing page and the public event page hide the ticketing call to action. Both sites guard on the value being non-blank before rendering a button, the landing page at MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Pages/Home/ADCHome.razor:71-75 and the public event page at MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Pages/Public/PublicEventDetail.razor:114-118, so a blank value is a supported product state rather than a validation failure. The 2000-character bound is the same constant the EF configuration applies to the column (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Infrastructure/Persistence/EntityConfiguration/Events/EventConfiguration.cs:69-70).
• Where it's used: Included by EventFieldRules<T> on p => p.TicketingUrl (EventValidationRules.cs:150), reaching both EventCreateRequestValidator and EventUpdateRequestValidator. A theory pins the rejection of a scheme-less host, a site-relative path, and a javascript: payload (EventCreateRequestValidatorTests.cs:205-209).
• Caveats / not-in-source: as with the sponsorship URL, no WithErrorCode is attached because the wrapped base is given none. Note also that the landing page's pre-conference ticketing button is a separate, hard-coded constant (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Pages/Home/ADCHome.razor.cs:29, used at ADCHome.razor:154) and does not flow through this field or this rule.

EventTimeZoneRules<T>

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Events.Validation · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Events/Validation/EventValidationRules.cs:25 · Level 7 · class (sealed, generic)

• What it is: a rule fragment for an event's time zone: non-empty, bounded by EventInvariants.TimeZoneMaxLength (100 characters, MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Domain/Events/EventInvariants.cs:23), and semantically checked to be a time-zone identifier the runtime actually recognizes. The doc comment ties the third rule to business requirement BR-87 (EventValidationRules.cs:21-22).
• Depends on: EventInvariants and System.TimeZoneInfo (BCL). It inherits AbstractValidator<T> directly.
• Concept: the same fragment shape as EventNameRules<T>, but it needs a predicate beyond string length, so it extends AbstractValidator<T> and adds a Must(...) rule backed by a private static predicate method. [Rubric §24, Forms, Validation & UX Safety] assesses whether the boundary rejects values the downstream code cannot use: proving the string resolves to a real time zone stops an unusable identifier from reaching scheduling logic. [Rubric §15, Best Practices & Code Quality] assesses defensive detail: the predicate catches only TimeZoneNotFoundException (:44), so an unexpected failure surfaces as an exception rather than being silently reported as "invalid input".
• Walkthrough: the constructor chains three rules on one selector (:28-32): NotEmpty with code Event.TimeZone.Required (:30), MaximumLength(EventInvariants.TimeZoneMaxLength) with code Event.TimeZone.MaxLength (:31), and Must(BeAValidIanaTimeZone) with code Event.TimeZone.InvalidIana and a message naming 'America/New_York' as the example form (:32). BeAValidIanaTimeZone (:34-48) returns true immediately for null or whitespace (:36-37), with an inline comment noting that NotEmpty already covers that branch, then calls TimeZoneInfo.FindSystemTimeZoneById(timeZone) inside a try (:39-43) and returns false only on TimeZoneNotFoundException (:44-47).
• Why it's built this way: returning true for the empty case avoids emitting two messages for one missing field. Delegating the identifier check to TimeZoneInfo reuses the platform's canonical time-zone database instead of hand-maintaining a list of identifiers. The domain repeats all three checks in EventInvariants.EnsureTimeZoneIsValid (EventInvariants.cs:82-102, with the codes Event.TimeZone.Empty, Event.TimeZone.TooLong, and Event.TimeZone.Invalid), so a caller that bypasses the validator still cannot persist an unknown zone. Note that the application-layer codes and the domain-layer codes are deliberately different strings for the same three conditions.
• Where it's used: Included by EventFieldRules<T> on p => p.TimeZone (EventValidationRules.cs:146), reaching both EventCreateRequestValidator and EventUpdateRequestValidator. The empty and valid-identifier cases are pinned at EventCreateRequestValidatorTests.cs:44 and :69.
• Caveats / not-in-source: FindSystemTimeZoneById resolves against the host operating system's time-zone database, so which identifiers are accepted can differ between a Windows developer machine and the Linux containers the services run in. Nothing in the rule pins that behavior, and the message says "IANA" while the lookup is whatever the host supports.

RoomAccessibilityInfoRules<T>

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Events.Validation · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Events/Validation/RoomValidationRules.cs:75 · Level 7 · class (sealed, generic)

• What it is: a rule fragment bounding a room's optional accessibility-info text to EventInvariants.RoomAccessibilityInfoMaxLength, 500 characters (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Domain/Events/EventInvariants.cs:56, MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Shared/Rooms/RoomDTO.cs:25).
• Depends on: OptionalStringRules<T>, its base class from the framework (MMCA.Common/Source/Core/MMCA.Common.Application/Validation/CommonValidationRules.cs:53), and EventInvariants, which re-exports the constant from RoomDTO.
• Concept: the same subclass-a-framework-fragment idiom taught on RoomSortRules<T>, applied to the optional-string case. Optionality is expressed in the base's own shape: OptionalStringRules<T> declares MaximumLength and nothing else, so a null value passes with no guard needed (CommonValidationRules.cs:55-57). [Rubric §15, Best Practices & Code Quality] assesses whether a constraint lives in exactly one place: the rule is written once in the framework, the bound once in the domain, and the module contributes only a label and a code.
• Walkthrough: the class declares : OptionalStringRules<T> (RoomValidationRules.cs:76) and forwards base(selector, "Accessibility Info", EventInvariants.RoomAccessibilityInfoMaxLength, "Room.AccessibilityInfo.MaxLength") from a constructor taking an Expression<Func<T, string?>> (:78-79). The base emits the message "Accessibility Info cannot be longer than 500 characters" carrying the supplied code.
• Why it's built this way: accessibility notes are free text an organizer may not have yet, so absence is valid; only the length is constrained, using the same constant the domain and the persistence configuration share. Passing the fourth errorCode argument is what keeps the field machine-addressable despite the rule being inherited.
• Where it's used: Included by AddRoomCommandValidator (AddRoomCommandValidator.cs:16) and UpdateRoomCommandValidator (UpdateRoomCommandValidator.cs:16), both on p => p.AccessibilityInfo; the overlong case is pinned at MMCA.ADC/Tests/Modules/Conference/MMCA.ADC.Conference.Application.Tests/Events/Validation/CommandValidatorTests.cs:161.

RoomFloorRules<T>

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Events.Validation · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Events/Validation/RoomValidationRules.cs:51 · Level 7 · class (sealed, generic)

• What it is: a rule fragment bounding a room's optional floor label to EventInvariants.RoomFloorMaxLength, 100 characters (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Domain/Events/EventInvariants.cs:50, MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Shared/Rooms/RoomDTO.cs:19).
• Depends on: OptionalStringRules<T> (MMCA.Common/Source/Core/MMCA.Common.Application/Validation/CommonValidationRules.cs:53) and EventInvariants.
• Concept: structurally identical to RoomAccessibilityInfoRules<T>: a nullable string? selector, one inherited MaximumLength rule, no NotEmpty.
• Walkthrough: : OptionalStringRules<T> (RoomValidationRules.cs:52) with the constructor forwarding base(selector, "Floor", EventInvariants.RoomFloorMaxLength, "Room.Floor.MaxLength") (:54-55).
• Why it's built this way: a floor is a label ("2", "Mezzanine"), not a required attribute of a room, so the fragment constrains only its length.
• Where it's used: Included by AddRoomCommandValidator (AddRoomCommandValidator.cs:14) and UpdateRoomCommandValidator (UpdateRoomCommandValidator.cs:14), both on p => p.Floor; the overlong case is pinned at CommandValidatorTests.cs:145.

RoomLocationRules<T>

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Events.Validation · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Events/Validation/RoomValidationRules.cs:63 · Level 7 · class (sealed, generic)

• What it is: a rule fragment bounding a room's optional location text to EventInvariants.RoomLocationMaxLength, 255 characters (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Domain/Events/EventInvariants.cs:53, MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Shared/Rooms/RoomDTO.cs:22).
• Depends on: OptionalStringRules<T> (MMCA.Common/Source/Core/MMCA.Common.Application/Validation/CommonValidationRules.cs:53) and EventInvariants.
• Concept: structurally identical to RoomFloorRules<T>. Reading the three optional room fragments together (:51, :63, :75) shows why the family exists at all: each is two lines, and the only things that vary are the invariant constant, the message noun, and the error code. [Rubric §2, Design Patterns] assesses whether a recurring shape is expressed as a reusable composition: the shared base owns the rule, and each field owns only its naming.
• Walkthrough: : OptionalStringRules<T> (RoomValidationRules.cs:64) with the constructor forwarding base(selector, "Location", EventInvariants.RoomLocationMaxLength, "Room.Location.MaxLength") (:66-67).
• Where it's used: Included by AddRoomCommandValidator (AddRoomCommandValidator.cs:15) and UpdateRoomCommandValidator (UpdateRoomCommandValidator.cs:15), both on p => p.Location; the overlong case is pinned at CommandValidatorTests.cs:153.

RoomNameRules<T>

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Events.Validation · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Events/Validation/RoomValidationRules.cs:13 · Level 7 · class (sealed, generic)

• What it is: a rule fragment for a room's name: non-empty and bounded by EventInvariants.RoomNameMaxLength, 255 characters (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Domain/Events/EventInvariants.cs:47, MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Shared/Rooms/RoomDTO.cs:16). It is the one required field among the room fragments.
• Depends on: EventInvariants. It inherits AbstractValidator<T> directly rather than a framework base.
• Concept: the same shape as EventNameRules<T>, but written out on AbstractValidator<T> rather than derived from RequiredStringRules<T>, even though the base would fit. Writing the chain locally buys two distinct error codes, one per bound, which the base cannot express: its single optional errorCode is applied to every rule it declares (MMCA.Common/Source/Core/MMCA.Common.Application/Validation/CommonValidationRules.cs:11-18, :43-46), so a field whose bounds must answer under different codes still declares its own rules. [Rubric §9, API & Contract Design] assesses the stability of the error contract clients consume: Room.Name.Required and Room.Name.MaxLength are separately addressable, whereas the event name yields a message only.
• Walkthrough: the constructor takes a single Expression<Func<T, string>> selector (:16) and chains NotEmpty with the message "You must enter a Room Name" and the code Room.Name.Required (:17-18), then MaximumLength(EventInvariants.RoomNameMaxLength) with the code Room.Name.MaxLength (:19).
• Why it's built this way: the required name is what distinguishes this fragment from the three optional room fields; keeping each field as its own fragment lets a command validator compose exactly the mix it needs, which is what the two room validators do line by line.
• Where it's used: Included by AddRoomCommandValidator (AddRoomCommandValidator.cs:11) and UpdateRoomCommandValidator (UpdateRoomCommandValidator.cs:11), both on p => p.Name; empty and overlong cases are pinned at CommandValidatorTests.cs:75, :84, and :129.
• Caveats / not-in-source: the length rule duplicates a domain-side check: EventInvariants.EnsureRoomNameIsValid enforces the same constant with the codes Room.Name.Empty and Room.Name.TooLong (EventInvariants.cs:135-138). The application fragment gives a fast, field-attributed failure; the domain invariant is the backstop that also fires for callers that bypass the validator.

EventFieldRules<T>

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Events.Validation · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Events/Validation/EventValidationRules.cs:139 · Level 8 · class (sealed, generic)

• What it is: the composite that assembles the six event field fragments into one rule set, declared once over IEventFieldsRequest. It is what the create and update validators actually include; neither of them names an individual fragment.
• Depends on: all six sibling fragments in the same file, EventNameRules<T>, EventTimeZoneRules<T>, EventDateRangeRules<T>, EventOrganizerContactEmailRules<T>, EventSponsorshipPacketUrlRules<T>, and EventTicketingUrlRules<T>, plus IEventFieldsRequest as its generic constraint and FluentValidation's AbstractValidator<T>.
• Concept, the shared-rule-set-plus-delta pattern. The fragments below it answer "how is one field validated"; this class answers "what does an event request validate at all". Because it is generic and constrained to the interface (EventValidationRules.cs:140-141), it is instantiated once per request type and each concrete validator reduces to an Include plus whatever its own operation adds. That is a different arrangement from a shared base validator: composition through Include means the create path pays nothing for the update path's extra rule, and a reader of either validator sees the full delta in two or three lines. [Rubric §1, SOLID] assesses open/closed adherence and dependency inversion: adding a shared field means adding a line here and a member to the interface, never editing a concrete validator; the composite binds to the abstraction. [Rubric §5, Vertical Slice] assesses whether a slice owns its own behavior: the create and update slices each keep their own validator file and their own delta, while sharing this one declaration. [Rubric §15, Best Practices & Code Quality] assesses duplication: without a shared declaration, six Include lines have to be kept identical across two files by hand, which is exactly the state the room validators are still in.
• Walkthrough: no fields, no parameters. The parameterless constructor (:143-151) issues six Include calls in field order: EventNameRules<T> on p => p.Name (:145), EventTimeZoneRules<T> on p => p.TimeZone (:146), EventDateRangeRules<T> on the p => p.StartDate, p => p.EndDate pair (:147), EventOrganizerContactEmailRules<T> on p => p.OrganizerContactEmail! (:148, the null-forgiving operator bridging the interface's string? to that fragment's non-nullable selector), EventSponsorshipPacketUrlRules<T> on p => p.SponsorshipPacketUrl (:149), and EventTicketingUrlRules<T> on p => p.TicketingUrl (:150). Every lambda binds against T's interface members, which is what the where T : IEventFieldsRequest constraint (:141) makes legal.
• Why it's built this way: the class doc comment states the intent directly (:133-137): each concrete request validator includes this and adds only the rules its own operation needs. That is visible on both sides. EventCreateRequestValidator is a single expression-bodied constructor, => Include(new EventFieldRules<EventCreateRequest>()) (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Events/UseCases/Create/EventCreateRequestValidator.cs:9-10), and EventUpdateRequestValidator includes the same set and then adds its one update-only rule, IsInEnum() on the live-layer moderation default under the code Event.QuestionModerationDefault.Invalid (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Events/UseCases/Update/EventUpdateRequestValidator.cs:11-18, with the reason for the asymmetry in the comment at :13-14).
• Where it's used: instantiated as EventFieldRules<EventCreateRequest> and EventFieldRules<EventUpdateRequest> by the two validators above, which the framework's validation decorator resolves in the CQRS pipeline (primer, 00-primer.md), so this rule set runs before either the create or the update handler executes. It is covered end to end by EventCreateRequestValidatorTests and EventUpdateRequestValidatorTests (MMCA.ADC/Tests/Modules/Conference/MMCA.ADC.Conference.Application.Tests/Events/Validation/EventCreateRequestValidatorTests.cs, MMCA.ADC/Tests/Modules/Conference/MMCA.ADC.Conference.Application.Tests/Events/Validation/EventUpdateRequestValidatorTests.cs), which exercise it through the concrete validators rather than directly.
• Caveats / not-in-source: the room fragments have no equivalent composite. AddRoomCommandValidator and UpdateRoomCommandValidator still repeat the same six Include lines each (AddRoomCommandValidator.cs:11-16, UpdateRoomCommandValidator.cs:11-16), because the two room commands share no interface the way the two event requests do.

BatchSessionQuestionAnswerItem

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Sessions.UseCases.BatchAddSessionQuestionAnswers · MMCA.ADC.Conference.Application/Sessions/UseCases/BatchAddSessionQuestionAnswers/BatchAddSessionQuestionAnswersCommand.cs:9 · Level 0 · record (sealed)

• What it is: one line of a session feedback form: the question being answered and the answer text. It is the element type of the batch command's Answers list and carries nothing else.
• Depends on: the QuestionIdentifierType alias (MMCA.ADC.Conference.Shared/MMCA.ADC.Conference.GlobalUsings.IdentifierType.cs) and a BCL string. No first-party types, nothing external.
• Concept introduced: the batch element that is not the single-answer command. The single-answer path has its own message, AddSessionQuestionAnswerCommand; this record deliberately is not that type reused as a list element. It drops the session id (the batch command states it once for the whole form, :23) and it drops the command markers, because one element is not independently dispatchable. [Rubric §9, API & Contract Design] assesses whether a contract says exactly what the operation needs: hoisting SessionId out of the element makes it structurally impossible to submit a form whose rows target different sessions. [Rubric §6, CQRS & Event-Driven] assesses message shape: the dispatchable unit is the whole form, so only the enclosing record is a command.
• Walkthrough: two positional members declared across three lines (:9-11), QuestionId and AnswerValue, documented individually above the declaration (:6-8). No body, no defaults, no validation of its own: the per-element rule (AnswerValue must be non-empty) is applied by BatchAddSessionQuestionAnswersCommandValidator through a RuleForEach child-rule block (BatchAddSessionQuestionAnswersCommandValidator.cs:22-26).
• Why it's built this way: it lives in the same file as the command rather than in a file of its own because it has no independent life: nothing constructs one except the API mapping step and the tests. Declaring it as a positional record gives value equality and immutability with no ceremony, which is what lets the validator's duplicate-question check treat the list as plain data.
• Where it's used: built by SessionQuestionAnswersController when it projects its own wire record BatchSessionQuestionAnswerItemRequest (MMCA.ADC.Conference.API/Controllers/Sessions/SessionQuestionAnswersController.cs:38-46) into command elements (:200-202), then read by BatchAddSessionQuestionAnswersHandler in both its validation pass (BatchAddSessionQuestionAnswersHandler.cs:89, :98) and its apply pass (:126).
• Caveats / not-in-source: there are two near-identical types on this path, this one and the controller's BatchSessionQuestionAnswerItemRequest (SessionQuestionAnswersController.cs:49). Nothing in source keeps their shapes in step; the mapping at :200-202 is the only place the two meet.

GetCategoryDistributionQuery

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Sessions.UseCases.DecisionSupport.GetCategoryDistribution · MMCA.ADC.Conference.Application/Sessions/UseCases/DecisionSupport/GetCategoryDistribution/GetCategoryDistributionQuery.cs:5 · Level 0 · record (sealed)

• What it is: the CQRS query contract that asks for the distribution of an event's sessions across its category items. A one-line record carrying nothing but the event to analyze.
• Depends on: the EventIdentifierType alias, an int in this module (MMCA.ADC.Conference.Shared/MMCA.ADC.Conference.GlobalUsings.IdentifierType.cs:8). No other first-party types, nothing external.
• Concept introduced: none new; this is a plain read-side CQRS request, and the query/handler split is taught by IQueryHandler<in TQuery, TResult>. What is worth noticing is that the record implements no marker interface: the pairing to a handler is purely the generic argument on IQueryHandler<GetCategoryDistributionQuery, Result<CategoryDistributionDTO>> (GetCategoryDistributionHandler.cs:15). [Rubric §6, CQRS & Event-Driven] assesses whether reads and writes travel separate paths with explicit contracts: this record is a read intent with no side effects, resolved by GetCategoryDistributionHandler.
• Walkthrough: one positional parameter, EventId of type EventIdentifierType (:5), documented by the two-line summary above it (:3-4). No body, no defaults.
• Why it's built this way: keeping the query as a standalone record means it can be dispatched on its own (an organizer opening the category-distribution view) or computed alongside the other decision-support dimensions by GetSessionSelectionDashboardHandler without one endpoint over-fetching for another.
• Where it's used: constructed by SessionSelectionController on GET SessionSelection/categories/{eventId} (MMCA.ADC.Conference.API/Controllers/Sessions/SessionSelectionController.cs:53-65), which resolves the handler through the injected IQueryHandler<GetCategoryDistributionQuery, Result<CategoryDistributionDTO>> (:32).

GetContentSimilarityQuery

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Sessions.UseCases.DecisionSupport.GetContentSimilarity · MMCA.ADC.Conference.Application/Sessions/UseCases/DecisionSupport/GetContentSimilarity/GetContentSimilarityQuery.cs:6 · Level 0 · record (sealed)

• What it is: the read request behind "which pairs of submitted sessions look like the same talk". It carries the event to analyze plus the score floor below which a pair is not worth showing.
• Depends on: the EventIdentifierType alias (MMCA.ADC.Conference.Shared/MMCA.ADC.Conference.GlobalUsings.IdentifierType.cs:8) and a BCL double. No first-party types.
• Concept introduced: the query that carries a tuning knob. The sibling decision-support queries are pure identity ("analyze this event"); this one also carries a policy value, MinimumSimilarity, with an in-contract default of 0.3 (:6). [Rubric §9, API & Contract Design] assesses whether a contract's optional inputs are explicit and defaulted in one place: here the default is stated twice, once on the record (:6) and once on the controller action parameter (MMCA.ADC.Conference.API/Controllers/Sessions/SessionSelectionController.cs:86), so an HTTP caller that omits minimumSimilarity never exercises the record's default at all. [Rubric §6, CQRS & Event-Driven] applies as for the sibling queries: a named read message resolved by exactly one IQueryHandler<in TQuery, TResult>.
• Walkthrough: two positional members (:6): EventId, and MinimumSimilarity defaulted to 0.3. The doc comment documents the intended range as 0.0 to 1.0 (:5). The value is used exactly once, as an inclusive lower bound in GetContentSimilarityHandler (GetContentSimilarityHandler.cs:74, score >= query.MinimumSimilarity), which is what HandleAsync_TreatsMinimumSimilarityAsInclusiveLowerBound pins (MMCA.ADC/Tests/Modules/Conference/MMCA.ADC.Conference.Application.Tests/Sessions/UseCases/DecisionSupport/GetContentSimilarityHandlerTests.cs:173).
• Why it's built this way: similarity is a judgment call, not a fact: an organizer sweeping for near-duplicate submissions wants a different floor than one looking only at blatant overlaps. Putting the knob on the query rather than in configuration lets the caller choose per request without a redeploy.
• Where it's used: constructed by SessionSelectionController on GET SessionSelection/content-similarity/{eventId} (SessionSelectionController.cs:81-94), binding minimumSimilarity from the query string (:86).
• Caveats / not-in-source: the 0.0 to 1.0 range is documentation only. The query pipeline does run a ValidatingQueryDecorator<TQuery, TResult> (MMCA.Common/Source/Core/MMCA.Common.Application/DependencyInjection.cs:141), but that decorator is a pass-through when no IValidator<TQuery> is registered (MMCA.Common/Source/Core/MMCA.Common.Application/UseCases/Decorators/ValidatingQueryDecorator.cs:69-72), and no validator exists for this query: the GetContentSimilarity folder holds only the query, the handler, and SessionSimilarityCalculator. A caller passing 5.0 therefore gets an empty pair list, and a negative floor returns every pair up to the handler's cap, both silently.

LocalityLookupEntry

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Sessions.UseCases.DecisionSupport · MMCA.ADC.Conference.Application/Sessions/UseCases/DecisionSupport/SpeakerLocalityHelper.cs:13 · Level 0 · record class (internal sealed)

• What it is: one entry of the merged speaker-locality lookup: a tier name plus the id of the locality category the item came from. It is declared in the same file as SpeakerLocalityHelper (SpeakerLocalityHelper.cs:13-15) because it is that helper's dictionary value type and nothing outside the helper constructs one.
• Depends on: the ConferenceCategoryIdentifierType alias, an int in this module (MMCA.ADC.Conference.Shared/MMCA.ADC.Conference.GlobalUsings.IdentifierType.cs:7). No other first-party types, nothing external beyond the BCL.
• Concept introduced: locality modelled as a category assignment that carries its import generation. A speaker's origin is not a column on Speaker: it is a SpeakerCategoryItem row pointing at a CategoryItem inside a "Where are you traveling from" Category (SpeakerLocalityHelper.cs:17-19, with the title match at :98-99). [Rubric §4, DDD] assesses whether concepts are expressed through the aggregates the domain actually has rather than through bolted-on fields; here the answer is read out of the existing category machinery, which is also what the Sessionize import populates. [Rubric §8, Data Architecture] explains the second field: Category is a global aggregate with no event scoping, so every yearly Sessionize refresh adds another locality category carrying fresh item ids (:82-84), and a returning speaker keeps the item from every year they answered the question (:51-52). A bare id-to-name lookup cannot say which year an item belongs to; pairing the name with its owning category id can, and that is the whole reason this record exists.
• Walkthrough: two positional members on a record class (:13-15). Name is the locality tier name, documented with the example "Atlanta and Suburbs" (:11); CategoryId is the identifier of the locality category owning the item (:12). The type is internal sealed, so it never leaves the Application assembly. Values are produced in exactly one place, BuildLocalityLookup, which walks the locality categories in ascending id order and writes lookup[item.Id] = new LocalityLookupEntry(item.Name, category.Id) for every non-deleted item (:128-136); they are consumed in exactly one place, GetLocalityTier, which walks the speaker's non-deleted assignments, looks each one up, and keeps the entry whose CategoryId is the highest seen so far (:43-58, the comparison at :53). Because the winner is chosen by comparison rather than by position, the order of the speaker's own assignments does not affect the answer.
• Why it's built this way: the "most recent import wins" rule needs a tiebreaker that survives merging several years of categories into one dictionary, and the owning category id is the only ordering signal available without a schema change (:7-9, :117-119). Declaring it a record gives value equality and immutability for free, which is what lets the helper treat entries as plain values while scanning.
• Where it's used: only inside the DecisionSupport folder, as the value type of the IReadOnlyDictionary<CategoryItemIdentifierType, LocalityLookupEntry> that SpeakerLocalityHelper builds and reads (:38, :123). That dictionary is threaded through two decision-support handlers: GetSessionSelectionDashboardHandler builds it once and passes it into its overlap, locality, and AI-score passes, and GetSpeakerSessionOverlapHandler does the same for its narrower view (MMCA.ADC.Conference.Application/Sessions/UseCases/DecisionSupport/GetSpeakerSessionOverlap/GetSpeakerSessionOverlapHandler.cs:52-53, :119).
• Caveats / not-in-source: the "highest category id is the most recent import" rule is an assumption about how Sessionize allocates category ids. The source states it twice as a comment (:51-52, :117-119) but nothing enforces or validates it, so an out-of-order id would silently resolve a returning speaker to an older tier. The behavior is pinned by SpeakerLocalityHelperTests (MMCA.ADC/Tests/Modules/Conference/MMCA.ADC.Conference.Application.Tests/Sessions/UseCases/DecisionSupport/SpeakerLocalityHelperTests.cs), which builds the entries directly and asserts that the newest-import tier wins regardless of assignment order, but the id ordering itself is an upstream property.

QuestionUpdateRequest

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Questions.UseCases.Update · MMCA.ADC.Conference.Application/Questions/UseCases/Update/QuestionUpdateRequest.cs:4 · Level 0 · record class

• What it is: the wire payload for editing an existing survey Question: its text, the entity it targets, its input type, its display order, and whether an answer is mandatory.
• Depends on: nothing first-party. All five members are BCL primitives, and the record implements no interface (QuestionUpdateRequest.cs:4).
• Concept introduced: a field that is in the contract but only conditionally editable. QuestionEntity (:10) and QuestionType (:13) are plain required string members here, so the wire contract accepts a new value for either. Whether that value is allowed is not a property of the record: UpdateQuestionHandler probes the three answer tables and rejects the change once any answer exists (BR-137, UpdateQuestionHandler.cs:41-75). Contrast this with a field removed from a request entirely, which is how the module expresses "never editable through this path". The distinction tells you where to look for a rule: a shape constraint lives in the record, a state-dependent constraint cannot, because the record has no access to the database. [Rubric §4, DDD] assesses whether rules live where the knowledge to enforce them lives. [Rubric §9, API & Contract Design] assesses contract uniformity: the payload stays the same between create and update, and the difference surfaces as a validation error with a stable code rather than as a missing property.
• Walkthrough: QuestionText (:7), QuestionEntity (:10, documented as "Session" or "Event"), and QuestionType (:13, documented as "Rating", "Text", or "Email") are required string with init setters. Sort (:16) and IsRequired (:19) are plain value members that default to 0 and false. Note the near-miss in naming: IsRequired is the survey question's own "an attendee must answer this" flag, not the C# required modifier that governs three of its siblings. There is no RowVersion member: the concurrency token travels beside the payload on UpdateQuestionCommand (UpdateQuestionCommand.cs:14), read from the If-Match header rather than from the body.
• Why it's built this way: the two discriminator strings are free-form string, not enums, so adding a question type or a new target entity does not require a change to the contract type; the legal values are asserted in the domain instead (QuestionInvariants, called from MMCA.ADC.Conference.Domain/Questions/Question.cs:116-118).
• Where it's used: bound by QuestionsController on PUT {id} (MMCA.ADC.Conference.API/Controllers/Questions/QuestionsController.cs:120), validated by QuestionUpdateRequestValidator, wrapped in UpdateQuestionCommand (:125), and consumed by UpdateQuestionHandler.

SessionSimilarityCalculator

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Sessions.UseCases.DecisionSupport.GetContentSimilarity · MMCA.ADC.Conference.Application/Sessions/UseCases/DecisionSupport/GetContentSimilarity/SessionSimilarityCalculator.cs:9 · Level 0 · class (internal static)

• What it is: the pure-function core of the content-similarity feature: it turns two sessions into a single number between 0.0 and 1.0 by blending category-item overlap (weight 0.6) with keyword overlap from title and description (weight 0.4).
• Depends on: System.Collections.Frozen.FrozenSet<string> and System.Linq from the BCL, plus the CategoryItemIdentifierType alias in one signature (:98-99). No first-party types at all: it never touches an entity, a repository, or a DTO.
• Concept introduced: the Jaccard index, and why the scoring logic is a static class. The Jaccard index of two sets is the size of their intersection divided by the size of their union, so identical sets score 1.0 and disjoint sets score 0.0. This file applies it twice, once to the two sessions' category-item id sets and once to their keyword sets, then blends the two with fixed weights (:103-105). Two sessions tagged identically but sharing no vocabulary score 0.6; two sessions sharing vocabulary but no tags score 0.4. [Rubric §14, Testability] assesses whether logic can be exercised without infrastructure: because every method is static and takes plain sets, SessionSimilarityCalculatorTests drives all four of them with literal inputs and no test double at all (MMCA.ADC/Tests/Modules/Conference/MMCA.ADC.Conference.Application.Tests/Sessions/UseCases/DecisionSupport/SessionSimilarityCalculatorTests.cs:6). [Rubric §12, Performance & Scalability] assesses hot-path cost: this runs once per session pair, so the code avoids per-character allocation and uses an O(1) frozen set for stop-word lookups. [Rubric §1, SOLID] assesses separation of responsibility: the scoring rule lives apart from the handler that orchestrates loading and DTO building, so a weight change touches one file.
• Walkthrough
  • CategoryWeight = 0.6 and KeywordWeight = 0.4 (:11-12), the only two tuning constants, private const and therefore not configurable at runtime.
  • StopWords, a FrozenSet<string> built once at type initialization with StringComparer.Ordinal (:14-34). It holds ordinary English function words and, deliberately, conference-generic vocabulary such as "SESSION", "TALK", "PRESENTATION", "DEEP", "DIVE", and "WORKSHOP" (:31-33), which would otherwise make every abstract look like every other abstract.
  • TokenizeText(string? text) (:41-71) returns an empty set for null or whitespace (:43-44), then scans the text as a ReadOnlySpan<char> with a manual index loop rather than string.Split (:48-68). A run of letters or digits ends at any other character or at end of input (:52); runs shorter than three characters are dropped (:62); surviving runs go to AddTokenIfNotStopWord (:123-130), which uppercases with ToUpperInvariant (the summary at :37 notes this is upper rather than lower to satisfy analyzer rule CA1308) and adds the token only if it is not a stop word.
  • CalculateJaccardIndex<T>(HashSet<T>, HashSet<T>) (:80-92) returns 0.0 when both sets are empty (:82-83), which is the guard against dividing by a zero union. It iterates the smaller set against the larger one's Contains (:85-88), then divides the intersection count by setA.Count + setB.Count - intersectionCount (:90-91).
  • CalculateSimilarity(...) (:97-106) is the blend: CategoryWeight * categoryScore + KeywordWeight * keywordScore.
  • GetIntersection<T>(...) (:115-121) returns the shared elements as a List<T>, again scanning the smaller set, and exists so the handler can show a reader why a pair scored what it scored.
• Why it's built this way: a single signal is too blunt for program selection. Category overlap alone flags every pair inside a broad track; keyword overlap alone flags any two talks that both say "Kubernetes". Weighting categories higher than keywords encodes that a shared explicit tag is stronger evidence than shared prose. Keeping all of it internal static with no dependencies means the rule is auditable and unit-testable in isolation, which is what the test class does.
• Where it's used: only by GetContentSimilarityHandler: TokenizeText while pre-computing per-session keyword sets (GetContentSimilarityHandler.cs:58), CalculateSimilarity inside the pairwise loop (:68-72), and GetIntersection twice when building each result row (:94-95).
• Caveats / not-in-source: two sessions with no category items at all score 0.0 on the category component, not 1.0, because the both-empty case returns zero by design (:82-83): "neither is tagged" is treated as no evidence rather than as agreement. Stop words are English only, and the token filter keeps digits, so a version number such as "2026" counts as a keyword. The weights and the three-character minimum are constants with no configuration path.

StatusBucket

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Sessions.UseCases.DecisionSupport.GetCategoryDistribution · MMCA.ADC.Conference.Application/Sessions/UseCases/DecisionSupport/GetCategoryDistribution/GetCategoryDistributionHandler.cs:94 · Level 0 · enum (private nested)

• What it is: the three-way bucket a session's status collapses into while the category-distribution tally runs: Accepted, AcceptQueue, or Pending (GetCategoryDistributionHandler.cs:94-99).
• Depends on: nothing. It is a bare enum with default backing type and no attributes, declared private inside GetCategoryDistributionHandler.
• Concept introduced: the private classification enum that never leaves its handler. The persisted vocabulary is the string constants on SessionStatuses, and the wire vocabulary is the four integer counters on CategoryItemDistribution. This enum is neither: it exists only for the few lines between classifying a session and incrementing a counter, which is why it is private rather than a shared type. [Rubric §9, API & Contract Design] assesses what a module exposes: making the bucket private keeps it out of every contract, so renaming or adding a bucket is a one-file change with no consumer impact. [Rubric §15, Best Practices & Code Quality] assesses intent-revealing code: comparing bucket == StatusBucket.AcceptQueue inside the fold (:57-59) reads as a decision already made, and the compiler makes the three cases exhaustive in a way three loose booleans would not.
• Walkthrough: three members in declaration order, Accepted, AcceptQueue, Pending (:96-98), so the implicit values are 0, 1, 2. Nothing depends on those numbers: the enum is only ever compared for equality. Values are produced in exactly one place, ClassifyStatus (:101-112), which maps a null status or SessionStatuses.Accepted to Accepted, SessionStatuses.AcceptQueue to AcceptQueue, and everything else to Pending, all with OrdinalIgnoreCase comparison. Declined sessions never reach it: CountSessionsPerCategoryItem filters them out first via IsDeclined (:44, :114-115), which is why there is no Declined member.
• Why it's built this way: the distribution view answers one question per category item ("how many total, accepted, queued, still open"), so the many persisted statuses have to fold into exactly the four columns the DTO carries. Doing that fold once, into a named enum, keeps the string comparison in a single method instead of repeating string.Equals(..., OrdinalIgnoreCase) three times inside the counting loop.
• Where it's used: only inside GetCategoryDistributionHandler.cs: returned by ClassifyStatus (:101), carried in the (CategoryItemId, Bucket) pairs that CountSessionsPerCategoryItem flattens each Session into (:47), and read three times when folding those pairs into the per-item tuple (:57-59).
• Caveats / not-in-source: because a null status classifies as Accepted (:103-107), an unset session inflates the accepted bucket rather than the pending one, and the enum offers no member to represent "unknown". There is also no Declined member even though the persisted vocabulary has that status: the filter upstream is the only thing keeping a declined session from being counted as Pending.

QuestionUpdateRequestValidator

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Questions.UseCases.Update · MMCA.ADC.Conference.Application/Questions/UseCases/Update/QuestionUpdateRequestValidator.cs:7 · Level 8 · class (sealed)

• What it is: the validator for QuestionUpdateRequest. One Include, covering the question text.
• Depends on: AbstractValidator<T> (FluentValidation, QuestionUpdateRequestValidator.cs:1,7), QuestionUpdateRequest, and QuestionTextRules<T> from MMCA.ADC.Conference.Application.Questions.Validation (:2, :10).
• Concept introduced: none new; it is the same one-line composition the module uses for every request validator. What is worth noticing is everything it does not validate. QuestionEntity and QuestionType are required strings with no rule here, even though only certain values are legal. Their legality is asserted twice further in: by QuestionInvariants inside Question.Update (MMCA.ADC.Conference.Domain/Questions/Question.cs:116-118), and, for the change rather than the value, by UpdateQuestionHandler's BR-137 probe. [Rubric §3, Clean Architecture] assesses whether each layer holds the checks it is entitled to hold: the validator owns cheap shape checks at the boundary, the aggregate owns the value invariants, and the handler owns the checks that require a database read.
• Walkthrough: sealed class QuestionUpdateRequestValidator : AbstractValidator<QuestionUpdateRequest> (:7) with an expression-bodied constructor (:9-10) that includes new QuestionTextRules<QuestionUpdateRequest>(p => p.QuestionText). That rule set is NotEmpty plus MaximumLength(QuestionInvariants.QuestionTextMaxLength), carrying the codes Question.QuestionText.Required and Question.QuestionText.MaxLength (MMCA.ADC.Conference.Application/Questions/Validation/QuestionValidationRules.cs:16-18).
• Why it's built this way: composing a shared rule object rather than restating RuleFor(x => x.QuestionText) in each validator means the create and update paths cannot drift on the same field: both take the identical QuestionTextRules<T> with a different type argument.
• Where it's used: executed by the ValidatingCommandDecorator<TCommand, TResult> through UpdateQuestionCommand, ahead of UpdateQuestionHandler.

SpeakerLocalityHelper

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Sessions.UseCases.DecisionSupport · MMCA.ADC.Conference.Application/Sessions/UseCases/DecisionSupport/SpeakerLocalityHelper.cs:21 · Level 8 · class (internal static)

• What it is: the small pure helper that answers "where is this speaker traveling from?" by reading the speaker's category assignments. It finds the locality categories among all loaded categories, flattens their items into one lookup, and resolves a speaker to a single tier name such as "Atlanta and Suburbs" or "Not North America" (SpeakerLocalityHelper.cs:17-19).
• Depends on: Category and CategoryItem (through Category.CategoryItems), Speaker and its SpeakerCategoryItem collection, LocalityLookupEntry as its dictionary value type, and the CategoryItemIdentifierType / ConferenceCategoryIdentifierType aliases (MMCA.ADC.Conference.Shared/MMCA.ADC.Conference.GlobalUsings.IdentifierType.cs:6-7). Nothing external beyond the BCL: no repository, no IUnitOfWork, no logger.
• Concept introduced: the pure in-memory helper beside a handler. Both decision-support handlers already load Category and Speaker graphs for other reasons, so the locality question is answered from data already in memory rather than by another query. Making the helper static with no injected dependencies means it is exercised directly in unit tests with hand-built aggregates and no test double at all. [Rubric §14, Testability] assesses whether logic can be tested without infrastructure: SpeakerLocalityHelperTests constructs speakers and categories in-process and asserts against all four public methods (MMCA.ADC/Tests/Modules/Conference/MMCA.ADC.Conference.Application.Tests/Sessions/UseCases/DecisionSupport/SpeakerLocalityHelperTests.cs). [Rubric §12, Performance & Scalability] assesses repeated work: the expensive step (scanning every category's items) happens once per request in BuildLocalityLookup, and the per-speaker step is a dictionary probe. [Rubric §8, Data Architecture] assesses how the model's shape drives the code: because Category has no event scoping, correctness here depends on merging categories across imports rather than picking one.
• Walkthrough, members in teaching order:
  • KnownLocalityCategoryId (:27), a private const holding 121854, the Sessionize identifier of the original "Where are you traveling from" category. It is the fallback used only when no category title matches the heuristic (:23-26).
  • FindLocalityCategories(IEnumerable<Category> categories) (:88) walks every category, skipping soft-deleted ones (:95-96), and collects those whose Title contains "traveling" or "Where are you based", case-insensitively (:98-102). A category that matches neither but carries the known id is remembered as fallback (:103-106). If nothing matched by title it returns the fallback as a single-element list, or an empty list (:109-110); otherwise it sorts the matches by ascending id and returns them (:112-113).
  • BuildLocalityLookup(IEnumerable<Category> localityCategories) (:123) iterates those categories in ascending id order (:128) and writes lookup[item.Id] = new LocalityLookupEntry(item.Name, category.Id) for every non-deleted item (:130-136). Ascending order is what makes the last write win, so a colliding item id resolves to the newest import (:116-119).
  • GetLocalityTier(Speaker speaker, IReadOnlyDictionary<CategoryItemIdentifierType, LocalityLookupEntry> localityCategoryItems) (:36-38) scans the speaker's SpeakerCategoryItems, skipping soft-deleted assignments (:45-46) and assignments whose item is not in the lookup (:48-49), and keeps the entry with the highest CategoryId seen (:53-57). It returns null when the speaker has no locality assignment at all (:40, :60).
  • IsLocalSpeaker(string? localityTier) (:69) returns false for null (:71-72) and otherwise reports whether the tier name contains "Atlanta", "Georgia", or "Surrounding", case-insensitively (:74-76).
• Why it's built this way: the regression this shape exists to fix is spelled out in the doc comment at :82-84: returning only the first (oldest) matching category left every speaker new to the current event resolving to no tier, because each yearly Sessionize refresh creates a fresh locality category with fresh item ids. Merging every locality category into one lookup, and breaking ties by highest owning category id, makes both a newcomer and a returning speaker resolve to their current-year answer. The title heuristic with an id fallback keeps the code working across two different question wordings without a configuration entry.
• Where it's used: GetSessionSelectionDashboardHandler calls FindLocalityCategories and BuildLocalityLookup once and GetLocalityTier in three projection passes; GetSpeakerSessionOverlapHandler does the same for its narrower view (MMCA.ADC.Conference.Application/Sessions/UseCases/DecisionSupport/GetSpeakerSessionOverlap/GetSpeakerSessionOverlapHandler.cs:52-53, :119).
• Caveats / not-in-source: two things are worth flagging. First, IsLocalSpeaker has no production caller: the only references are its declaration (:69) and the theory in SpeakerLocalityHelperTests, so the "local speaker" notion is defined and tested but not yet consumed by a handler. Second, the tier match is substring-based, so any future tier name containing "Georgia" or "Surrounding" would be classified local without a code change; nothing in source constrains the set of tier names Sessionize can produce.

UpdateQuestionCommand

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Questions.UseCases.Update · MMCA.ADC.Conference.Application/Questions/UseCases/Update/UpdateQuestionCommand.cs:15 · Level 8 · record (sealed)

• What it is: the write intent for updating a Question: route id, the QuestionUpdateRequest body, and the caller's optimistic-concurrency token, marked as cache-invalidating.
• Depends on: ICommandWithRequest<out TRequest> and ICacheInvalidating (UpdateQuestionCommand.cs:15), QuestionUpdateRequest (:15), and the Question type for its FullName (:1, :18). QuestionIdentifierType is the module identifier alias.
• Concept introduced: the concurrency token as a command member, not a body member. The token is a third positional parameter (:14) rather than a field on the request record, and its doc comment states both where it comes from and that it is not optional: the caller's last-observed version, read from the If-Match header, on an endpoint where "a conditional update that states no precondition never reaches this command" (:9-13). [Rubric §9, API & Contract Design] assesses where a precondition belongs: If-Match is an HTTP-level precondition, so it is lifted off the body by the controller and handed to the command as data, keeping the JSON payload free of transport concerns. [Rubric §8, Data Architecture] assesses concurrency control: this is the ADR-035 optimistic-concurrency contract (Website/docs-src/adr/035-optimistic-concurrency.md), enforced by the base handler rather than by this record.
• Walkthrough: sealed record UpdateQuestionCommand(QuestionIdentifierType Id, QuestionUpdateRequest Request, byte[] RowVersion) with both interfaces on the declaration (:14), and one computed member, CachePrefix => $"{typeof(Question).FullName}:" (:17). The prefix is what the cache-invalidating decorator uses to evict every cached read of the question aggregate after a successful write.
• Why it's built this way: the type is byte[], not string, because that is the shape EF Core stamps back onto the tracked entity; encoding and decoding the ETag is the API layer's job (SupportsIfMatchAttribute). Declaring the parameter non-nullable states the endpoint's contract in the type system: an unconditional caller is rejected at the boundary with 428, never here.
• Where it's used: constructed by QuestionsController on PUT {id} (MMCA.ADC.Conference.API/Controllers/Questions/QuestionsController.cs:126), with the token pulled from the request by SupportsIfMatchAttribute.RequiredToken(HttpContext) (:122), against the injected ICommandHandler<UpdateQuestionCommand, Result<QuestionDTO>> (:37), and handled by UpdateQuestionHandler.

BatchAddSessionQuestionAnswersCommand

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Sessions.UseCases.BatchAddSessionQuestionAnswers · MMCA.ADC.Conference.Application/Sessions/UseCases/BatchAddSessionQuestionAnswers/BatchAddSessionQuestionAnswersCommand.cs:22 · Level 9 · record (sealed)

• What it is: the write intent for submitting a whole session feedback form in one request: the session being answered plus the list of answers, one per question.
• Depends on: BatchSessionQuestionAnswerItem as its element type (:24), ICacheInvalidating and ITransactional (:2, :24), the Session type for its FullName (:1, :27), and the SessionIdentifierType alias.
• Concept introduced: ITransactional as an all-or-nothing declaration on the message. The module's decorator pipeline reads markers off the command type rather than off the handler: TransactionalCommandDecorator<TCommand, TResult> is registered innermost of the command decorators (MMCA.Common/Source/Core/MMCA.Common.Application/DependencyInjection.cs:131) and opens a transaction only for commands carrying ITransactional. Adding the marker here is therefore the entire mechanism by which a partially applied form becomes unobservable, and the doc comment says exactly that (:17-18). [Rubric §6, CQRS & Event-Driven] assesses whether cross-cutting behavior is declared on the message and applied by the pipeline rather than hand-rolled in each handler: the handler contains no transaction code at all. [Rubric §8, Data Architecture] assesses write atomicity: one transaction plus one SaveChangesAsync means an accepted form is one durable unit, which also keeps the outbox rows this write produces in the same commit (ADR-003). [Rubric §12, Performance & Scalability] assesses request economy: the doc comment records the batch's real payoff, which is that the session, its owning event, and every referenced question are read once instead of once per answer (:15-17).
• Walkthrough: two positional members (:22-24), SessionId and Answers typed as IReadOnlyList<BatchSessionQuestionAnswerItem>, with both markers on the declaration (:24) and one computed member, CachePrefix => $"{typeof(Session).FullName}:" (:27), which evicts the session aggregate's cached reads after a successful write. The class-level summary is where the semantics live: every answer is upserted the same way the single-answer command does (BR-107), and the form is accepted or refused together (:13-19).
• Why it's built this way: the alternative, having the client loop the single-answer endpoint, gives the same rows but not the same guarantees: a network failure halfway through leaves a half-saved form the client has to reconcile, and every call repeats the session, event, and question reads. Declaring the whole form as one message moves both problems into the pipeline (ADR-014).
• Where it's used: constructed by SessionQuestionAnswersController on POST SessionQuestionAnswers/batch (MMCA.ADC.Conference.API/Controllers/Sessions/SessionQuestionAnswersController.cs:192-210, the command built at :200-202) against the injected ICommandHandler<BatchAddSessionQuestionAnswersCommand, Result<IReadOnlyList<SessionQuestionAnswerDTO>>> (:79), validated by BatchAddSessionQuestionAnswersCommandValidator, and handled by BatchAddSessionQuestionAnswersHandler.
• Caveats / not-in-source: the endpoint also carries IdempotentAttribute (SessionQuestionAnswersController.cs:193), so a retry with the same Idempotency-Key replays the first response (ADR-017) rather than re-applying the form. That replay contract lives on the action, not on this record: dispatching the same command twice through the handler directly would run the BR-107 upsert twice.

GetCategoryDistributionHandler

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Sessions.UseCases.DecisionSupport.GetCategoryDistribution · MMCA.ADC.Conference.Application/Sessions/UseCases/DecisionSupport/GetCategoryDistribution/GetCategoryDistributionHandler.cs:14 · Level 9 · class (sealed)

• What it is: the query handler that computes, per category item, how many of an event's sessions were submitted, accepted, put in the accept queue, or left pending. It backs the organizer's category-distribution view during session selection.
• Depends on: IQueryHandler<in TQuery, TResult> (implemented) and IUnitOfWork (the only constructor dependency, :14-15); Session and Category as repository entities plus CategoryItem through their collections; SessionStatuses for the status constants; the nested StatusBucket enum; and the output contracts CategoryDistributionDTO, CategoryGroupDistribution, and CategoryItemDistribution from MMCA.ADC.Conference.Shared.Sessions.DecisionSupport (:3).
• Concept introduced: the in-memory analytics read handler. It loads two aggregate sets untracked and then does all filtering, bucketing, and grouping in C#, rather than pushing aggregation down into SQL. [Rubric §6, CQRS & Event-Driven] assesses the read path: this is a pure query returning Result<CategoryDistributionDTO> and mutating nothing, so it is wrapped only by the query-side decorators the framework registers (Timeout, Validating, Caching, Logging, Authorization, FeatureGate, MMCA.Common/Source/Core/MMCA.Common.Application/DependencyInjection.cs:140-145), never by the command-side Transactional one (:129). [Rubric §12, Performance & Scalability] assesses read efficiency: both loads pass asTracking: false (:27, :32) so EF skips change tracking, and the tally is a single pass into a dictionary rather than a nested scan (:50-61). [Rubric §5, Vertical Slice] assesses feature cohesion: query, handler, and private bucketing live in one GetCategoryDistribution folder, so the whole feature is readable in one place.
• Walkthrough: HandleAsync (:17-39) resolves a Session repository and a Category repository from the unit of work (:21-22). It loads the event's sessions with SessionCategoryItems included, filtered to s.EventId == query.EventId && !s.IsServiceSession (:24-28), then loads every category with its CategoryItems (:30-33), with no event filter because categories are global. CountSessionsPerCategoryItem (:41-64) drops declined sessions via IsDeclined (:45, :114-115), flattens each remaining session into (CategoryItemId, StatusBucket) pairs while skipping soft-deleted links (:46-48), and folds those pairs into a (Total, Accepted, AcceptQueue, Pending) tuple per category item (:50-61). ClassifyStatus (:101-112) treats a null status or SessionStatuses.Accepted as Accepted, SessionStatuses.AcceptQueue as AcceptQueue, and anything else as Pending, all with OrdinalIgnoreCase comparison. BuildCategoryGroups (:66-92) keeps only non-deleted categories that have at least one counted item (:70), orders categories by Sort (:71) and items by Sort (:78), and projects each item into a CategoryItemDistribution with its four counts, using TryGetValue so an uncounted item yields zeros (:81-90). The handler returns Result.Success(new CategoryDistributionDTO { Categories = categoryGroups }) (:38): it has no failure path.
• Why it's built this way: aggregating in memory keeps the handler engine-agnostic (the same code runs against whatever store backs IUnitOfWork, per the database-per-service model of ADR-006) and states the domain rules (service sessions excluded, declined excluded, soft-deletes excluded at both the session-link and category-item levels) as readable filters instead of burying them in SQL. The trade-off is that a full event's sessions and the full category set are materialized; that is bounded by one conference's proposal volume.
• Where it's used: injected into SessionSelectionController as IQueryHandler<GetCategoryDistributionQuery, Result<CategoryDistributionDTO>> (MMCA.ADC.Conference.API/Controllers/Sessions/SessionSelectionController.cs:32) and invoked from GET SessionSelection/categories/{eventId} (:53-65), an endpoint gated on the SessionSelectionManage permission at the controller level (:29) and output-cached under the ConferenceCache policy (:55). Behavior is pinned by GetCategoryDistributionHandlerTests (MMCA.ADC/Tests/Modules/Conference/MMCA.ADC.Conference.Application.Tests/Sessions/UseCases/DecisionSupport/GetCategoryDistributionHandlerTests.cs:13).
• Caveats / not-in-source: a null Session.Status is counted as Accepted (:103-107), so a session whose status was never set inflates the accepted column rather than the pending one. The branch is explicit in code, but the reason for choosing Accepted over Pending as the null default is not stated there. The handler also resolves the read-write GetRepository (:21-22) although it only reads: IUnitOfWork exposes a narrower GetReadRepository alongside it (MMCA.Common/Source/Core/MMCA.Common.Application/Interfaces/Infrastructure/Persistence/IUnitOfWork.cs:19 versus :29).

GetContentSimilarityHandler

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Sessions.UseCases.DecisionSupport.GetContentSimilarity · MMCA.ADC.Conference.Application/Sessions/UseCases/DecisionSupport/GetContentSimilarity/GetContentSimilarityHandler.cs:14 · Level 9 · class (sealed)

• What it is: the query handler that scores every pair of an event's live sessions for content overlap and returns the strongest pairs, each annotated with the tags and words the two proposals share.
• Depends on: IQueryHandler<in TQuery, TResult> (implemented) and IUnitOfWork (the only constructor dependency, :14-15); SessionSimilarityCalculator for the scoring; Session, Category, and CategoryItem as loaded aggregates; SessionStatuses for the declined filter; and the output contracts ContentSimilarityDTO and SimilarSessionPair (:3).
• Concept introduced: the bounded quadratic analytical query. Unlike its sibling handlers, which fold each session once, this one compares every session against every other one: a double loop with j = i + 1 (:64-79), so a 200-proposal event performs 19,900 comparisons. Three separate mechanisms keep that honest. First, the expensive per-session work (tokenizing title plus description, materializing the category-item id set) is hoisted out of the loop and done once per session (:51-59), so the loop body is only set arithmetic. Second, only sessions that can still be scheduled are loaded at all: the where predicate excludes service sessions and declined ones in the database (:29-31). Third, the result is capped at MaxPairs = 50 (:17, :83-86). [Rubric §12, Performance & Scalability] assesses exactly this shape: quadratic work is acceptable here because n is one conference's proposal count and the constant factor is a hash-set intersection, but the cost is real and the cap bounds the response, not the computation. [Rubric §9, API & Contract Design] assesses response determinism, which is why the sort is not a plain score sort (see the walkthrough). [Rubric §6, CQRS & Event-Driven] applies as for the sibling handlers: a pure read wrapped only by the query-side decorators.
• Walkthrough: HandleAsync (:19-114) resolves Session and Category repositories (:23-24), loads the event's non-service, non-declined sessions with SessionCategoryItems included and asTracking: false (:27-33), and loads all categories with their items (:36-39) purely to build an id-to-name lookup for the shared-tag labels (:41-48). It then projects each session into an anonymous value of (Session, CategoryItems, Keywords) (:51-59), where CategoryItems skips soft-deleted links (:56) and Keywords comes from SessionSimilarityCalculator.TokenizeText(s.Title + " " + s.Description) (:58). The pairwise loop scores each combination and keeps the pair when score >= query.MinimumSimilarity (:64-79): the bound is inclusive, which is what HandleAsync_TreatsMinimumSimilarityAsInclusiveLowerBound pins (MMCA.ADC/Tests/Modules/Conference/MMCA.ADC.Conference.Application.Tests/Sessions/UseCases/DecisionSupport/GetContentSimilarityHandlerTests.cs:173). Sorting uses the explicit comparer CompareByScoreThenIndex (:82, :120-132): score descending, then index A, then index B. The tie-break is the load-bearing part, and the summary above the comparer says why (:116-119): a plain score comparison leaves equal-scoring pairs in unspecified relative order, so truncating to 50 could return a different 50 for the same input (HandleAsync_WithTiedScores_TruncatesToADeterministicTopFifty, GetContentSimilarityHandlerTests.cs:319). Truncation is GetRange(0, MaxPairs) (:83-86). Each surviving pair becomes a SimilarSessionPair (:89-111) carrying both sessions' id, title, and status, the score rounded to three decimals with MidpointRounding.ToEven (:105), the shared category items resolved to names (:106-108), and at most ten shared keywords (:109). The method ends with Result.Success(new ContentSimilarityDTO { Pairs = result }) (:113) and has no failure path.
• Why it's built this way: the point of the feature is a conversation between organizers, so the output has to be explainable: showing the shared tags and words next to the number is what makes a pair actionable rather than merely flagged. The deterministic comparer exists because the response is output-cached and read by humans comparing runs, so a stable list is worth the extra comparisons. Doing the whole computation in memory keeps the scoring rule in C# where it is unit-testable, rather than in SQL where it would not be.
• Where it's used: injected into SessionSelectionController as IQueryHandler<GetContentSimilarityQuery, Result<ContentSimilarityDTO>> (MMCA.ADC.Conference.API/Controllers/Sessions/SessionSelectionController.cs:34) and invoked from GET SessionSelection/content-similarity/{eventId} (:81-94). The dashboard path does not use it: GetSessionSelectionDashboardHandler computes distribution, overlap, locality, and AI scores but no similarity block, so this handler is reachable only through its own endpoint.
• Caveats / not-in-source: the 50-pair cap truncates silently: the response carries no flag saying more pairs cleared the threshold. Sessions with neither tags nor keywords score 0.0 against each other and are therefore returned when the caller passes a floor of 0.0 (GetContentSimilarityHandlerTests.cs:207). The declined filter is expressed as s.Status != SessionStatuses.Declined (:31), a comparison translated to SQL, whereas the sibling handlers compare statuses with OrdinalIgnoreCase in memory; whether the two agree on casing depends on the database collation, which this file does not state.

BatchAddSessionQuestionAnswersCommandValidator

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Sessions.UseCases.BatchAddSessionQuestionAnswers · MMCA.ADC.Conference.Application/Sessions/UseCases/BatchAddSessionQuestionAnswers/BatchAddSessionQuestionAnswersCommandValidator.cs:10 · Level 10 · class (sealed)

• What it is: the boundary validator for BatchAddSessionQuestionAnswersCommand. Three rules: the form has at least one answer, no question is answered twice in the same request, and no answer value is blank.
• Depends on: AbstractValidator<T> (FluentValidation, :1, :10), BatchAddSessionQuestionAnswersCommand, and BatchSessionQuestionAnswerItem through the child rules. Nothing else.
• Concept introduced: the collection-shape rule that protects an upsert. The interesting rule is the second one (:18-20): it fails the request when the answers contain a duplicate QuestionId. That check exists because the handler applies BR-107 as an upsert keyed on (CreatedBy, QuestionId, SessionId) (BatchAddSessionQuestionAnswersHandler.cs:128-130), and two rows targeting the same question inside one request would make the upsert fight itself: the second row would find the first row's freshly added answer or silently overwrite it, depending on tracking order. Rejecting the shape up front is cheaper and far more explainable than handling that inside the loop. [Rubric §15, Best Practices & Code Quality] assesses whether a constraint is expressed where it is cheapest to check: this is a pure function of the payload, so it belongs in the validator, not the handler. [Rubric §6, CQRS & Event-Driven] assesses pipeline placement: the rule runs in ValidatingCommandDecorator<TCommand, TResult>, which sits outside the transaction (MMCA.Common/Source/Core/MMCA.Common.Application/DependencyInjection.cs:131-133), so a malformed form never opens one.
• Walkthrough: the constructor holds three registrations (:12-27). RuleFor(x => x.Answers).NotEmpty() with the message "At least one answer is required." (:14-16). RuleFor(x => x.Answers).Must(...) comparing answers.Select(a => a.QuestionId).ToHashSet().Count against answers.Count, null-tolerant, with the message "Each question may be answered only once per request." (:18-20). RuleForEach(x => x.Answers).ChildRules(...) applying NotEmpty() to each AnswerValue with the message "Answer value is required." (:22-26). All four behaviors are pinned by BatchAddSessionQuestionAnswersCommandValidatorTests (MMCA.ADC/Tests/Modules/Conference/MMCA.ADC.Conference.Application.Tests/Sessions/Validation/SessionCommandValidatorTests.cs:39-84), including the blank-answer case, which uses a whitespace-only string (:80) because FluentValidation's NotEmpty treats whitespace as empty.
• Why it's built this way: the class summary states the design intent explicitly (:5-9): apply the same non-empty answer rule the single-answer validator applies, plus the batch-only shape rules. Keeping the per-answer rule identical between the two surfaces is what makes the batch endpoint a pure optimization rather than a second, subtly different contract.
• Where it's used: resolved by the validating decorator from the DI container as an IValidator<BatchAddSessionQuestionAnswersCommand> and run ahead of BatchAddSessionQuestionAnswersHandler. It is never invoked directly by the handler or the controller.
• Caveats / not-in-source: the duplicate check runs on the identifier only, so two answers to different questions with identical text pass, as they should. It says nothing about whether the questions exist or target sessions: that is BR-128, checked by the handler against the database (BatchAddSessionQuestionAnswersHandler.cs:100-103).

BatchAddSessionQuestionAnswersHandler

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Sessions.UseCases.BatchAddSessionQuestionAnswers · MMCA.ADC.Conference.Application/Sessions/UseCases/BatchAddSessionQuestionAnswers/BatchAddSessionQuestionAnswersHandler.cs:22 · Level 10 · class (sealed partial)

• What it is: the handler that applies a whole session feedback form in one request. It loads the session once, checks the session-level rules once and each answer against its question, upserts every answer onto the tracked aggregate, and commits the lot with a single SaveChangesAsync.
• Depends on: ICommandHandler<in TCommand, TResult> (implemented, :27), IUnitOfWork (:22), ICurrentUserService (:23), SessionQuestionAnswerDTOMapper (:24), TimeProvider and ILogger<T> from the BCL and Microsoft.Extensions (:25-26); the aggregates Session, Event, and Question plus the SessionQuestionAnswer child (:3-5); SessionQuestionAnswerRules for the shared business rules; the SessionFeedbackSubmitted domain event (:7); Result and Error (:10); and SessionQuestionAnswerDTO as the response element.
• Concept introduced: the batch handler that must not become a second contract. The temptation with a batch endpoint is to write a faster, looser version of the single-answer path. This handler is built to make that impossible: every rule it enforces is called out of SessionQuestionAnswerRules, the same static class the single-answer handler calls (MMCA.ADC.Conference.Application/Sessions/SessionQuestionAnswerRules.cs:14, used here at :82-83 and :100-103, and in AddSessionQuestionAnswerHandler.cs:70, :80). That class exists precisely so the two surfaces share one definition of BR-91, BR-49, BR-108, BR-128 and BR-124 (SessionQuestionAnswerRules.cs:8-13), and both of its methods take the already-loaded Event and Question as parameters rather than looking them up, which is what lets the batch path read each of them once (SessionQuestionAnswerRules.cs:17-19, :50-51). [Rubric §1, SOLID] assesses whether a rule has one owner: the rules are neither duplicated nor subclassed, they are passed their inputs. [Rubric §5, Vertical Slice] assesses whether a slice can be added without disturbing its neighbor: the batch slice is its own folder and reuses the shared rules rather than editing the single-answer slice. [Rubric §12, Performance & Scalability] assesses N+1 avoidance: the referenced questions are read in one GetAllAsync with a Contains predicate (:91-95) and indexed into a dictionary (:96), so a 12-question form issues three reads, not 14. [Rubric §6, CQRS & Event-Driven] assesses event emission: the cross-module notification is raised on the aggregate, per newly created answer, and delivered through the outbox on the same commit (ADR-003).
• Walkthrough, three methods in the order they run:
  • HandleAsync (:30-68) guards the command (:34), resolves the Session repository and loads the session with its SessionQuestionAnswers included and asTracking: true (:36-41), because the upsert mutates the loaded graph. A missing session returns Error.NotFound decorated with source and target (:42-47). It then calls ValidateAsync (:49-53) and Apply (:55-59), propagating either failure without writing, destructures the applied answers and the created count (:61), issues the single SaveChangesAsync (:63), logs (:64), and maps each applied answer to a DTO (:66-67).
  • ValidateAsync (:75-111) loads the session's owning Event (:80-81) and runs SessionQuestionAnswerRules.EnsureSessionAcceptsFeedback once for the whole form (:82-87), which covers BR-91 (no service sessions), BR-49 (eligible status) and BR-108 (published parent event, with a NotFound when the event could not be read, SessionQuestionAnswerRules.cs:41-46). It then collects the distinct question ids (:89), reads them all through the read-only repository untracked (:90-95), builds a dictionary (:96), and checks each answer with EnsureAnswerIsValid (:98-108), which covers BR-128 (the question exists and targets "Session") and BR-124 (the value matches the question type). The first failure returns immediately, so the whole form is refused on one bad row.
  • Apply (:118-161) reads the current user id (:122) and walks the answers. For each one it looks for a live answer by the same user to the same question (:129-130, the BR-107 key) and, when found, calls session.UpdateSessionQuestionAnswer(existing.Id, answer.AnswerValue) (:134); otherwise it calls session.AddSessionQuestionAnswer(null, answer.QuestionId, answer.AnswerValue) (:144) and raises one SessionFeedbackSubmitted on the aggregate carrying the user, session, event, and the TimeProvider-supplied timestamp (:155-156), incrementing createdCount (:157). Either domain failure aborts the whole apply pass (:135-138, :145-148). The method deliberately persists nothing; the comment at :115-116 records that the caller owns the single save.
  • LogAnswersSubmitted (:163-164) is the [LoggerMessage] partial, logging the session id, the applied count, and the newly created count.
• Why it's built this way: raising the feedback event only on the create path (:152-154) is the rule that keeps Engagement's points award honest: editing an answer is not new feedback, so re-submitting a form awards nothing extra, and the batch path emits exactly what the single-answer path emits when the same form is submitted one call at a time. Splitting validation and application into two passes means no answer is ever written before every answer has been checked, which is what makes the ITransactional marker on the command mostly a belt-and-braces guarantee rather than the only one.
• Where it's used: injected into SessionQuestionAnswersController as ICommandHandler<BatchAddSessionQuestionAnswersCommand, Result<IReadOnlyList<SessionQuestionAnswerDTO>>> (MMCA.ADC.Conference.API/Controllers/Sessions/SessionQuestionAnswersController.cs:79) and invoked from POST SessionQuestionAnswers/batch (:192-210). Behavior is pinned by BatchAddSessionQuestionAnswersHandlerTests (MMCA.ADC/Tests/Modules/Conference/MMCA.ADC.Conference.Application.Tests/Sessions/UseCases/BatchAddSessionQuestionAnswers/BatchAddSessionQuestionAnswersHandlerTests.cs:25), whose names state the contract directly: the form is refused and nothing is written when the session is missing (:138), when the parent event is unpublished (:155), when a question does not target sessions (:180), and when an answer does not match its question type (:205); a valid form creates every answer in one save (:231); the feedback event is raised once per created answer (:261); and an existing answer is updated without raising it (:293).
• Caveats / not-in-source: currentUserService.UserId!.Value is dereferenced unconditionally (:122), so an unauthenticated invocation would throw rather than return a failure; the endpoint's [Authorize] (SessionQuestionAnswersController.cs:75) is what keeps that unreachable in production. The handler resolves the read-write GetRepository for the Event it only reads (:80), unlike the questions read which uses GetReadRepository (:90).

UpdateQuestionHandler

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Questions.UseCases.Update · MMCA.ADC.Conference.Application/Questions/UseCases/Update/UpdateQuestionHandler.cs:19 · Level 14 · class (sealed partial)

• What it is: the handler for UpdateQuestionCommand. It rides the framework's shared load-mutate-save workflow and inserts one extra gate: a question's type and target entity may not change once anybody has answered it (BR-137).
• Depends on: MutateEntityHandlerBase<TCommand, TEntity, TIdentifierType> in its four-parameter DTO flavor (:23), IUnitOfWork (:20), QuestionDTOMapper (:21), ILogger<T> (:22), Result and Error (:10), the Question aggregate (:4), and the three answer entities EventQuestionAnswer (:3), SessionQuestionAnswer (:5), and SpeakerQuestionAnswer (:6).
• Concept introduced: the state-dependent immutability check, and how a handler contributes it to a template-method workflow. Two ideas meet here. The first is the rule itself: some constraints cannot live in the request record (it has no data) or in the aggregate (a Question does not hold its answers; those live in separate tables reached through their own repositories). BR-137 is one of them, because changing QuestionType from "Rating" to "Text" after answers exist would leave stored answers that no longer make sense under the new type. The second is the shape: this handler declares no HandleAsync at all. The load, the NotFound, the concurrency stamp, the save, and the DTO mapping are all supplied by MutateEntityHandlerCore<TCommand, TEntity, TIdentifierType> (MMCA.Common/Source/Core/MMCA.Common.Application/UseCases/Crud/MutateEntityHandlerBase.cs:271-309) and its DTO-returning subclass (:342-360); the handler contributes four small overrides. [Rubric §2, Design Patterns] assesses the template method: the base fixes the algorithm and names the variation points, so a new update handler is four overrides rather than forty lines of repeated orchestration. [Rubric §4, DDD] assesses where knowledge lives: BR-137 is a cross-aggregate rule, and the application layer is the only place that can see both sides of it. [Rubric §12, Performance & Scalability]: the probe block is guarded behind a cheap comparison (:41-42), so the common edit (fixing a typo, reordering) costs zero extra queries, and the three ExistsAsync calls short-circuit as soon as one returns true. [Rubric §1, SOLID]: the aggregate stays ignorant of collections it does not own.
• Walkthrough: sealed partial class with primary-constructor DI, passing unitOfWork and dtoMapper up to the base (:19-23). Four overrides follow.
  • EntityId (:26) returns command.Id, telling the base which aggregate to load.
  • RowVersion (:32) returns command.RowVersion, which is what opts this handler into optimistic concurrency: the base stamps the token as the entity's original row version when it is non-empty (MutateEntityHandlerBase.cs:291-292), so a concurrent edit surfaces as a DbUpdateConcurrencyException and a 412 instead of last-write-wins. The comment above the override records that intent (:28-29), and the base's default returns null for unconditional endpoints (MutateEntityHandlerBase.cs:91).
  • MutateAsync (:35-83) is the domain step, called by the base with the loaded, tracked aggregate. The BR-137 block fires only when entity.QuestionType != command.Request.QuestionType || entity.QuestionEntity != command.Request.QuestionEntity (:41-42). It probes event answers (:44-47), then session answers if still clean (:51-54), then speaker answers (:61-64, with a comment recording that speaker answers count the same as the other two), each through UnitOfWork.GetReadRepository<...>() (the read-only face declared at MMCA.Common/Source/Core/MMCA.Common.Application/Interfaces/Infrastructure/Persistence/IUnitOfWork.cs:29), which both states the intent and keeps those entities out of the change tracker. On a hit it returns Error.Validation with code Question.ImmutableAfterAnswers, an explanatory message, and source and target (:67-74). Past the gate it returns entity.Update(questionText, questionEntity, questionType, sort, isRequired) (:77-82), which re-runs the value invariants and raises QuestionChanged (MMCA.ADC.Conference.Domain/Questions/Question.cs:108, :116-118, :128). A failure here short-circuits before the base's save, so a refused invariant never writes (MutateEntityHandlerBase.cs:294-296).
  • LogMutated (:86-87) is the post-save logging hook, calling the [LoggerMessage] partial LogQuestionUpdated declared at :89-90. The base calls it only after a successful save (MutateEntityHandlerBase.cs:305).
• Why it's built this way: the refusal is an Error.Validation with a stable code rather than a thrown exception, so it travels the same Result channel as a FluentValidation failure and the controller's shared HandleFailure turns it into a client-error response with no special case (MMCA.ADC.Conference.API/Controllers/Questions/QuestionsController.cs:128-129). Overriding MutateAsync rather than HandleAsync is what keeps the ADR-035 concurrency stamp and the DTO mapping identical across every update handler in the module.
• Where it's used: injected into QuestionsController as ICommandHandler<UpdateQuestionCommand, Result<QuestionDTO>> (MMCA.ADC.Conference.API/Controllers/Questions/QuestionsController.cs:38) and invoked on PUT {id} (:112-132), after which the controller evicts the conference:questions output-cache tag (:131).
• Caveats / not-in-source: the BR-137 check is a read followed by a write with no lock between them, so an answer submitted in the window between the probe and the save is not caught. The row version protects the question row, not the answer tables. Whether that race has ever occurred in practice is not determinable from source.

GetSessionSelectionDashboardQuery

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Sessions.UseCases.DecisionSupport.GetSessionSelectionDashboard · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Sessions/UseCases/DecisionSupport/GetSessionSelectionDashboard/GetSessionSelectionDashboardQuery.cs:5 · Level 0 · record (sealed)

• What it is - the read request for the whole session-selection screen in one call: summary counts, category distribution, speaker overlap, speaker locality, and AI scores for one event.
• Depends on - the EventIdentifierType alias, an int in this module (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Shared/MMCA.ADC.Conference.GlobalUsings.IdentifierType.cs:8). Nothing else.
• Concept introduced - the composite (screen-shaped) query. The other decision-support queries each answer one question; this one is deliberately shaped like the UI page rather than like a single analytical question, and its handler computes every dimension from one set of loads (GetSessionSelectionDashboardHandler.cs:12-15). [Rubric §9 - API & Contract Design] assesses whether the contract fits its consumer: one round trip for a screen that would otherwise need several, at the cost of a response the narrower endpoints do not need. [Rubric §12 - Performance & Scalability] assesses request economy: the sessions, categories, and speakers are read once and reused across every computed block instead of once per block. The query/handler split itself is taught by IQueryHandler<in TQuery, TResult> and is cross-referenced rather than re-taught here.
• Walkthrough - one positional parameter, EventId of type EventIdentifierType (:5), with the summary and <param> doc above it (:3-4). No body, no defaults, no marker interface: the pairing to a handler is purely the generic argument on IQueryHandler<GetSessionSelectionDashboardQuery, Result<SessionSelectionDashboardDTO>> (GetSessionSelectionDashboardHandler.cs:17).
• Why it's built this way - the Blazor page is the only consumer that needs all the dimensions, and it needs them consistent with each other. Answering them from one snapshot of loaded data means the counts on the page cannot disagree between panels.
• Where it's used - constructed by SessionSelectionController on GET SessionSelection/dashboard/{eventId} (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.API/Controllers/Sessions/SessionSelectionController.cs:39-51), resolved through the injected IQueryHandler<GetSessionSelectionDashboardQuery, Result<SessionSelectionDashboardDTO>> (:31). That endpoint is the one the UI actually calls: SessionSelectionService requests sessionselection/dashboard/{eventId} and deserializes SessionSelectionDashboardDTO (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Services/Sessions/Selection/SessionSelectionService.cs:14-32, the url at :26), and calls none of the narrow decision-support endpoints.

GetSpeakerSessionOverlapQuery

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Sessions.UseCases.DecisionSupport.GetSpeakerSessionOverlap · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Sessions/UseCases/DecisionSupport/GetSpeakerSessionOverlap/GetSpeakerSessionOverlapQuery.cs:5 · Level 0 · record (sealed)

• What it is - the read request for the speaker-centric view of an event's submissions: who submitted what, with the multi-session speakers surfaced first.
• Depends on - the EventIdentifierType alias (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Shared/MMCA.ADC.Conference.GlobalUsings.IdentifierType.cs:8). Nothing else.
• Concept - none new; it is the same one-field read message as GetSessionSelectionDashboardQuery, which teaches the shape. [Rubric §5 - Vertical Slice] assesses feature cohesion: this record sits in the same GetSpeakerSessionOverlap folder as its handler, so the whole capability is one directory.
• Walkthrough - one positional parameter, EventId (:5); the summary above it states the intent as "find speakers with multiple submitted sessions" (:3). Note that the handler's own doc comment corrects that scope: it returns EVERY speaker with at least one submitted session (GetSpeakerSessionOverlapHandler.cs:11-17).
• Why it's built this way - speaker overlap is a distinct selection concern from topic balance (one speaker holding three accepted slots is a program problem even when the topic mix is fine), so it gets its own message and its own endpoint rather than being a filter over the category view.
• Where it's used - constructed by SessionSelectionController on GET SessionSelection/speaker-overlap/{eventId} (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.API/Controllers/Sessions/SessionSelectionController.cs:67-79), through the injected IQueryHandler<GetSpeakerSessionOverlapQuery, Result<SpeakerSessionOverlapDTO>> (:33).

ScoreEventSessionsCommand

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Sessions.UseCases.DecisionSupport.ScoreEventSessions · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Sessions/UseCases/DecisionSupport/ScoreEventSessions/ScoreEventSessionsCommand.cs:5 · Level 0 · record (sealed)

• What it is - the write message that says "score every non-service session on this event with the AI model". One positional EventId and nothing else.
• Depends on - the EventIdentifierType alias (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Shared/MMCA.ADC.Conference.GlobalUsings.IdentifierType.cs:8). Nothing external.
• Concept introduced - the command nobody sends from a request thread. Unlike the other commands in this group, no controller ever constructs this record. The HTTP surface enqueues an event id instead (see ISessionScoringQueue), and the only construction site is the hosted drain worker resolving the handler inside its own DI scope (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Infrastructure/Sessions/Scoring/SessionScoringProcessor.cs:190-193). [Rubric §6 - CQRS & Event-Driven] assesses whether writes travel as explicit messages: keeping the run a real ICommandHandler<in TCommand, TResult> command rather than a plain service method means the drain worker goes through the same handler pipeline a controller dispatch would. [Rubric §12 - Performance & Scalability] assesses request economy: the expensive work is named here and executed elsewhere, so the request thread returns in milliseconds.
• Walkthrough - one positional parameter, EventId (:5), with the one-line summary above it (:3-4).
• Why it's built this way - a scoring run takes minutes and issues one paid Anthropic call per session (ISessionScoringQueue.cs:19-21). Modelling it as a command lets the queue carry only an id while the handler stays a normal, testable use case.
• Where it's used - resolved and dispatched by SessionScoringProcessor as ICommandHandler<ScoreEventSessionsCommand, Result<ScoreEventSessionsResultDTO>> (SessionScoringProcessor.cs:190-193); handled by ScoreEventSessionsHandler.

[Rubric §16, AI-Native Application Architecture] applies: this type is part of the AI session-scoring feature (a model call behind a port, versioned prompt and model, an evaluation gate, metered spend; ADR-111).

SessionScoringEnqueueResult

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Sessions.UseCases.DecisionSupport.ScoreEventSessions · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Sessions/UseCases/DecisionSupport/ScoreEventSessions/ISessionScoringQueue.cs:4 · Level 0 · enum

• What it is - the three-valued answer to "did my scoring request get in": Queued, AlreadyPending, or QueueFull (:7, :10, :13).
• Depends on - nothing. It is a bare enum with default integer backing and no attributes.
• Concept introduced - the tri-state accept, and why it is not a bool. A boolean enqueue result would collapse two refusals that need different words at the API edge: "your run is already in flight, do nothing" versus "the queue is saturated, come back". The controller maps them to distinct problem codes on the same HTTP status, SessionScoring.AlreadyRunning and SessionScoring.QueueFull, both 409 (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.API/Controllers/Sessions/SessionSelectionController.cs:112-130, the 409 declared at :109). [Rubric §9 - API & Contract Design] assesses whether a refusal is expressed with enough fidelity for a caller to act on it: an operator seeing "already running" waits, an operator seeing "queue full" retries. [Rubric §29 - Resilience & Business Continuity] assesses back-pressure: refusing outright is the deliberate alternative to blocking a request thread on a bounded channel.
• Walkthrough - three members in acceptance order, each with a one-line doc comment stating the caller's next move (:6-13). There is no None or Unknown member: every path through TryEnqueue returns one of the three explicitly (SessionScoringQueue.cs:69, :72, :76).
• Why it's built this way - the dedup decision and the capacity decision are made at different points inside TryEnqueue (a lost TryAdd versus a failed TryWrite), so the return type carries both outcomes rather than forcing the caller to re-inspect the queue.
• Where it's used - returned by ISessionScoringQueue.TryEnqueue (ISessionScoringQueue.cs:36), produced by SessionScoringQueue, switched on by SessionSelectionController.ScoreSessions (SessionSelectionController.cs:112), and inspected by SessionScoringSweepJob after its recovery enqueue (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Infrastructure/Sessions/Scoring/SessionScoringSweepJob.cs:181).

[Rubric §16, AI-Native Application Architecture] applies: this type is part of the AI session-scoring feature (a model call behind a port, versioned prompt and model, an evaluation gate, metered spend; ADR-111).

SessionScoringResult

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Sessions.UseCases.DecisionSupport.ScoreEventSessions · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Sessions/UseCases/DecisionSupport/ScoreEventSessions/IAiScoringService.cs:54 · Level 0 · record (sealed)

• What it is - what the AI scorer hands back for one session: seven numeric sub-scores, the model's free-text Reasoning, and a Success flag that says whether any of it means anything.
• Depends on - the SessionIdentifierType alias (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Shared/MMCA.ADC.Conference.GlobalUsings.IdentifierType.cs:15) and BCL decimal, string, bool. No first-party types.
• Concept introduced - the never-throw service result. IAiScoringService contracts that scoring never throws and reports failure in the result instead (IAiScoringService.cs:9), and this record is the vehicle. The adapter's failure path builds it with every score at 0m, Reasoning = "Scoring failed", and Success = false (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Infrastructure/Sessions/Scoring/AnthropicScoringService.cs:366-379), so one bad session never aborts a loop over hundreds. [Rubric §29 - Resilience & Business Continuity] assesses whether a flaky external dependency degrades one item or the whole run: here it degrades one. [Rubric §13 - Observability & Operability] assesses whether an outcome is legible after the fact: Reasoning is persisted onto SessionAiScore alongside the model id, so an organizer can see why a session scored what it scored and which model said so.
• Walkthrough - ten required init members (:43-70): SessionId; the seven decimal scores OverallScore, TopicRelevanceScore, DescriptionQualityScore, NoveltyScore, ActionableTakeawaysScore, DepthOrInsightQualityScore, CredibilityExperienceScore, each documented as 1.0 to 10.0; Reasoning; and Success. required on all ten means no partially-populated instance can be constructed, which is what lets the handler read result.SessionId rather than the loop variable when building the entity (ScoreEventSessionsHandler.cs:80).
• Why it's built this way - the 1.0 to 10.0 range in the doc comments is documentation on this record only. The invariant is enforced one layer in, by SessionAiScore.Create (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Domain/Sessions/SessionAiScore.cs:77), whose EnsureScoreInRange rejects anything outside >= 1.0m and <= 10.0m with a SessionAiScore.OutOfRange error (:134-141). Keeping the transport record permissive and the entity strict means a model that returns nonsense produces a counted failure instead of a corrupt row.
• Where it's used - returned by IAiScoringService.ScoreSessionAsync (IAiScoringService.cs:11-13), produced by AnthropicScoringService and by FakeAiScoringService in the integration test host (MMCA.ADC/Tests/Integration/MMCA.ADC.Conference.IntegrationTests/Infrastructure/FakeAiScoringService.cs), consumed by ScoreEventSessionsHandler (:70-83). It is application-internal: the shape the API returns is SessionAiScoreDTO.
• Caveats / not-in-source - a Success = false result carries all-zero scores, which SessionAiScore.Create would reject outright. Nothing in the type enforces that pairing; the handler simply never reaches Create on a failed result because it checks Success first (ScoreEventSessionsHandler.cs:72-77).

[Rubric §16, AI-Native Application Architecture] applies: this type is part of the AI session-scoring feature (a model call behind a port, versioned prompt and model, an evaluation gate, metered spend; ADR-111).

SessionScoringWorkItem

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Sessions.UseCases.DecisionSupport.ScoreEventSessions · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Sessions/UseCases/DecisionSupport/ScoreEventSessions/SessionScoringQueue.cs:21 · Level 0 · readonly record struct

• What it is - one queued scoring run: which event to score, and which attempt this is. Two values in a readonly record struct marked [StructLayout(LayoutKind.Auto)] (:20-21).
• Depends on - the EventIdentifierType alias (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Shared/MMCA.ADC.Conference.GlobalUsings.IdentifierType.cs:8), plus System.Runtime.InteropServices.StructLayoutAttribute (:2). No first-party dependencies.
• Concept introduced - retry state that travels with the message. The obvious alternative is a side table of "how many times have I tried event 7", owned by the drain worker. Carrying Attempt on the item instead means the worker keeps no per-event state at all: it reads an item, and if the run throws it re-queues the same item with Attempt + 1 (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Infrastructure/Sessions/Scoring/SessionScoringProcessor.cs:143). The doc comment names the price honestly: a crash between the failure and the requeue loses the retry, which is the intended floor for an in-process, best-effort queue that an organizer can always trigger again (:9-14). [Rubric §29 - Resilience & Business Continuity] assesses whether the durability level of a mechanism is chosen and stated rather than assumed. [Rubric §12 - Performance & Scalability] applies in a small way: a struct element in a Channel<T> avoids a heap allocation per enqueue, and LayoutKind.Auto lets the runtime pack the fields.
• Walkthrough - two positional members (:21): EventId and Attempt. Attempt is documented as 1 for the original request, incremented by one on each bounded retry the drain worker schedules (:17-19); the constant supplying that initial 1 lives on the queue as FirstAttempt (SessionScoringQueue.cs:41).
• Why it's built this way - a readonly record struct gives value equality and immutability with no allocation, which suits a message that is written, read once, and discarded.
• Where it's used - the element type of the queue's bounded Channel<SessionScoringWorkItem> (SessionScoringQueue.cs:43-49), written by TryEnqueue (:71) and TryRequeue (:97), read by SessionScoringProcessor through queue.Reader.ReadAllAsync (SessionScoringProcessor.cs:107).
• Caveats / not-in-source - the retry ceiling is not on this type. MaxAttempts = 3 is a private constant on the drain worker (SessionScoringProcessor.cs:74), checked at :143, so nothing in the item itself stops a different consumer from re-queuing forever.

[Rubric §16, AI-Native Application Architecture] applies: this type is part of the AI session-scoring feature (a model call behind a port, versioned prompt and model, an evaluation gate, metered spend; ADR-111).

SpeakerInfo

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Sessions.UseCases.DecisionSupport.ScoreEventSessions · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Sessions/UseCases/DecisionSupport/ScoreEventSessions/IAiScoringService.cs:37 · Level 0 · record (sealed)

• What it is - the slice of a speaker that the AI model is allowed to see: full name, optional tagline, optional biography (:23-26).
• Depends on - nothing but BCL strings. Notably it does not carry the SpeakerIdentifierType (a Guid in this module, MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Shared/MMCA.ADC.Conference.GlobalUsings.IdentifierType.cs:19), nor an email, a photo url, or any other Speaker field.
• Concept introduced - the minimized projection at an external boundary. Everything in this record leaves the system: AnthropicScoringService concatenates the name, tagline, and bio straight into the prompt body it posts to Anthropic (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Infrastructure/Sessions/Scoring/AnthropicScoringService.cs:257-261). Building a purpose-shaped record instead of passing the entity means the set of fields that can reach a third party is a three-line declaration a reviewer can read at a glance. [Rubric §30 - Compliance/Privacy/Data Governance] assesses data minimization at a processor boundary: the identifier is deliberately absent, so what leaves is speaker-authored public bio text with no key to join it back. [Rubric §11 - Security] assesses whether such a boundary is explicit rather than incidental; here it is a type, not a convention.
• Walkthrough - three positional members (:23-26), the last two nullable. The handler builds one per non-deleted SessionSpeaker it can resolve, from speaker.FullName, speaker.TagLine, speaker.Bio (ScoreEventSessionsHandler.cs:61-67).
• Why it's built this way - a scoring prompt needs the speaker's credibility signals and nothing else. Widening the model would silently widen what is sent to a paid third-party API, which is the kind of change a dedicated record forces into review.
• Where it's used - as the Speakers list on SessionScoringInput (IAiScoringService.cs:51); constructed only in ScoreEventSessionsHandler (:64).
• Caveats / not-in-source - the doc comments state "max 500 chars" for TagLine and "max 4000 chars" for Bio (:21-22), but nothing in this record, the handler, or the Anthropic adapter truncates or validates either value: the adapter escapes and PII-redacts them before appending, but never truncates (AnthropicScoringService.cs:257-261). Treat those numbers as descriptive of the source fields, not as an enforced bound on the prompt. A different, unrelated SpeakerInfo exists in the Conference UI assembly (SpeakerInfo); the two only share a name.

StatusBucket

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Sessions.UseCases.DecisionSupport.GetSessionSelectionDashboard · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Sessions/UseCases/DecisionSupport/GetSessionSelectionDashboard/GetSessionSelectionDashboardHandler.cs:314 · Level 0 · enum (private, nested)

• What it is - the private three-member enum nested inside GetSessionSelectionDashboardHandler that collapses a session's free-text status string onto the three columns the dashboard's category tally reports.
• Depends on - nothing structurally. Values are produced from the SessionStatuses string constants by the handler's own ClassifyStatus (:321-332).
• Concept introduced - a handler-local aggregation vocabulary. Session.Status is free text imported from Sessionize, and SessionStatuses names six recognized values: Accepted, Waitlisted, AcceptQueue, Nominated, DeclineQueue, Declined (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Domain/Sessions/SessionStatuses.cs:17-32). The distribution view does not want six columns, so the handler declares a private three-member enum and folds everything that is neither accepted nor accept-queue into Pending. [Rubric §15 - Best Practices & Code Quality] assesses local reasoning: the bucket type is an implementation detail no caller can see, so the handler can change its bucketing without touching anything else. [Rubric §15 - Best Practices & Code Quality] assesses expressiveness: three named members read better at the tally site than three ad-hoc string comparisons.
• Walkthrough - three members, Accepted, AcceptQueue, Pending (:314-319). There is deliberately no Declined member, because declined sessions are removed before any bucketing happens: CountCategoryItems filters them with IsDeclined first (:137, :334-335). ClassifyStatus (:321-332) maps a null status or SessionStatuses.Accepted to Accepted, SessionStatuses.AcceptQueue to AcceptQueue, and everything else to Pending, comparing with StringComparison.OrdinalIgnoreCase.
• Why it's built this way - declined proposals do not compete for a slot, so they are dropped before the enum stage and the three live buckets stay meaningful. Keeping the enum private to the handler avoids a shared type that would couple two otherwise independent use cases.
• Where it's used - inside its own handler only: the tally in CountCategoryItems (:150-152) and ClassifyStatus (:321-332). Callers receive CategoryDistributionDTO counts, never a bucket value.
• Caveats / not-in-source - a second, independent StatusBucket with the same three members is declared inside GetCategoryDistributionHandler (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Sessions/UseCases/DecisionSupport/GetCategoryDistribution/GetCategoryDistributionHandler.cs:94), with its own matching ClassifyStatus. Nothing in source keeps the two copies in step. A null Session.Status counts as Accepted here (:323-327), which is consistent with the domain's public-visibility allow-list, where an unset status is eligible because organizer-created sessions never carry one (SessionStatuses.cs:47-51), but the code does not restate the reason at the bucketing site. Waitlisted, Nominated, and DeclineQueue all land in Pending with no way to tell them apart in the output.

StatusBucket

MMCA.ADC.Conference.Application · ...DecisionSupport.GetCategoryDistribution and ...DecisionSupport.GetSessionSelectionDashboard · see table · Level 0 · enum (private, nested, two declarations)

• What it is: two independent private enums, one nested in each of the two handlers that tally sessions by status, that collapse a session's free-text status string onto the three columns those tallies report.

• Depends on: nothing structurally. Both are produced from the SessionStatuses string constants by their handler's ClassifyStatus.
• Concept introduced: a handler-local aggregation vocabulary. Session.Status is free text imported from Sessionize, and SessionStatuses names the recognized values (Accepted, Waitlisted, AcceptQueue, Nominated, DeclineQueue, Declined). The distribution views do not want a column per value, so each handler declares a private three-member enum and folds everything that is neither accepted nor accept-queue into Pending. [Rubric §15, Best Practices & Code Quality] assesses local reasoning: the bucket type is an implementation detail no caller can see, so either handler can change its bucketing without touching the other. [Rubric §15, Best Practices & Code Quality] assesses expressiveness: three named members read better at the tally site than three ad-hoc string comparisons.
• Walkthrough: three members in each declaration: Accepted, AcceptQueue, Pending (GetCategoryDistributionHandler.cs:96-98). There is deliberately no Declined member, because declined sessions are removed before any bucketing happens: IsDeclined filters them out in CountSessionsPerCategoryItem (:45, declared at :114-115). ClassifyStatus (:101-112) maps a null status or SessionStatuses.Accepted to Accepted (:103-107), SessionStatuses.AcceptQueue to AcceptQueue, and everything else to Pending (:109-111), comparing with StringComparison.OrdinalIgnoreCase throughout.
• Why it's built this way: declined proposals do not compete for a slot, so they are dropped before the enum stage and the three live buckets stay meaningful. Keeping the enum private to each handler avoids a shared type that would couple two otherwise independent use cases.
• Where it's used: inside its own handler only: GetCategoryDistributionHandler (:58-60, :101-112) and GetSessionSelectionDashboardHandler. Callers receive DTO counts, never a bucket value.
• Caveats / not-in-source: a null Session.Status counts as Accepted in both copies (GetCategoryDistributionHandler.cs:103-107). That is consistent with the domain's treatment of organizer-created sessions, which never carry an imported status, but the code does not restate the reason at the bucketing site. Waitlisted, Nominated, and DeclineQueue all land in Pending with no way to tell them apart in the output.

ISessionScoringQueue

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Sessions.UseCases.DecisionSupport.ScoreEventSessions · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Sessions/UseCases/DecisionSupport/ScoreEventSessions/ISessionScoringQueue.cs:31 · Level 1 · interface

• What it is - the producer-side port for AI scoring runs: ask for an event to be scored, or ask whether one is already in flight. Two methods, neither async.
• Depends on - SessionScoringEnqueueResult (same file, :4) and the EventIdentifierType alias (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Shared/MMCA.ADC.Conference.GlobalUsings.IdentifierType.cs:8). Nothing external.
• Concept introduced - the request-shedding work queue, and why fire-and-forget was not enough. The interface's own doc comment (:16-30) is the design record for the whole feature. Scoring an event takes minutes and issues one paid Anthropic call per session, so it cannot run on the request thread; it previously ran as a fire-and-forget task started from the controller, which had three named problems: nothing tracked it, so a deploy or scale-in killed it mid-run with no record; nothing deduplicated it, so two clicks meant two concurrent passes over the same event, doubling the spend and racing each other's writes; and it ignored the host lifetime, so shutdown could not wait for or cancel it (:20-24). The port answers all three by handing the work to a hosted drain. Note the deliberate dedup choice: a second request is refused rather than silently coalesced, so the caller learns the run is already in flight (:26-29). [Rubric §29 - Resilience & Business Continuity] assesses whether long work survives the request that started it. [Rubric §31 - Cost/FinOps] assesses spend control on a metered dependency: dedup here is a money guard as much as a correctness one. [Rubric §3 - Clean Architecture] assesses the direction of dependency: the port is declared in Application, while the channel implementation and the hosted worker that drains it are wired nearer the host, so the controller sees neither.
• Walkthrough - TryEnqueue(EventIdentifierType) (:36) returns SessionScoringEnqueueResult rather than a bool, so the caller can distinguish "already pending" from "queue full". IsPending(EventIdentifierType) (:40) reports whether a run is queued or currently executing, not merely waiting: the implementation holds the claim until the run finishes (SessionScoringQueue.cs:51-55). Both methods are synchronous, which is what makes the enqueue safe to call from an MVC action with no awaits at all.
• Why it's built this way - separating the producer port from the concrete SessionScoringQueue keeps the consumer side (Reader, TryRequeue, MarkCompleted) off the interface the API layer can reach. A controller can only ask; only the drain worker, which resolves the concrete class, can consume or complete.
• Where it's used - injected into SessionSelectionController for POST SessionSelection/score/{eventId} (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.API/Controllers/Sessions/SessionSelectionController.cs:35, :106-131) and into SessionScoringSweepJob, the crash-recovery backstop that re-enqueues events whose pass started but never finished (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Infrastructure/Sessions/Scoring/SessionScoringSweepJob.cs:56, rationale at :10-20). Registered as a singleton that forwards to the one concrete instance (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/DependencyInjection.cs:64-65).

[Rubric §16, AI-Native Application Architecture] applies: this type is part of the AI session-scoring feature (a model call behind a port, versioned prompt and model, an evaluation gate, metered spend; ADR-111).

SessionScoringInput

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Sessions.UseCases.DecisionSupport.ScoreEventSessions · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Sessions/UseCases/DecisionSupport/ScoreEventSessions/IAiScoringService.cs:47 · Level 1 · record (sealed)

• What it is - everything the AI scorer is given about one session: its id, title, optional description, and the SpeakerInfo projections for its speakers (:33-37).
• Depends on - SpeakerInfo (same file, :23) and the SessionIdentifierType alias (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Shared/MMCA.ADC.Conference.GlobalUsings.IdentifierType.cs:15). External: IReadOnlyList<T> only.
• Concept - none new; it is the request half of the never-throw port taught at IAiScoringService, and the minimization rationale is taught at SpeakerInfo. [Rubric §3 - Clean Architecture] assesses whether an external capability is described in the application's own language: this record names a session and its speakers, not a prompt, a token budget, or a JSON body, all of which stay inside the Infrastructure adapter.
• Walkthrough - four positional members (:33-37). Speakers is documented as possibly empty (:32), and the handler does produce an empty list for a session whose speaker links resolve to nothing (ScoreEventSessionsHandler.cs:61-67). SessionId is carried through the call and echoed back on SessionScoringResult, which is what lets the handler pair a result with its session without holding a map.
• Why it's built this way - passing a purpose-built input record rather than the Session entity keeps the domain aggregate out of the adapter and keeps the prompt's ingredients auditable in four lines.
• Where it's used - the sole payload parameter of IAiScoringService.ScoreSessionAsync (:11-13); built once per session by ScoreEventSessionsHandler (:69), consumed by AnthropicScoringService.

[Rubric §16, AI-Native Application Architecture] applies: this type is part of the AI session-scoring feature (a model call behind a port, versioned prompt and model, an evaluation gate, metered spend; ADR-111).

IAiScoringService

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Sessions.UseCases.DecisionSupport.ScoreEventSessions · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Sessions/UseCases/DecisionSupport/ScoreEventSessions/IAiScoringService.cs:6 · Level 2 · interface

• What it is - the application-layer port for scoring one conference session with an AI model, plus two provenance properties: which model did the scoring, and which version of the prompt contract it was asked with.
• Depends on - SessionScoringInput and SessionScoringResult, both declared in this same file (:47, :54), which in turn use SpeakerInfo (:37). External: BCL only. There is no Anthropic client type anywhere in the Application assembly.
• Concept introduced - port and adapter for an unreliable, paid, external capability. [Rubric §3 - Clean Architecture] assesses which layer owns the abstraction: the application declares the port, while the HTTP client, the prompt text, the JSON contract records, and the API key all live in Infrastructure's AnthropicScoringService, bound by AddHttpClient<IAiScoringService, AnthropicScoringService> (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Infrastructure/DependencyInjection.cs:33). [Rubric §1 - SOLID] assesses the dependency-inversion direction: ScoreEventSessionsHandler depends on this interface, so swapping vendors touches one registration. [Rubric §29 - Resilience & Business Continuity] assesses failure containment: the "Never throws (failure is indicated in the result)" clause (:9) is the Result philosophy applied to a network call, and it is what lets the handler's per-session loop keep going. [Rubric §13 - Observability & Operability] assesses whether an AI output can be explained after the fact: the port makes both the model id (:16) and the prompt version (:30) part of the contract, so every stored score carries the two inputs that decide what it means (the governance rule is ADR-111, Website/docs-src/adr/111-ai-session-scoring-governance.md). [Rubric §14 - Testability] assesses whether the use case can run without the dependency: FakeAiScoringService implements this interface, so the scoring path is exercised with no HTTP and no API key.
• Walkthrough
  • ScoreSessionAsync(SessionScoringInput, CancellationToken = default) (:11-13) returns Task<SessionScoringResult>. There is no Result<T> here and no exception path: the success or failure signal is the Success flag on the returned record.
  • ModelId { get; } (:16) exposes which model produced a score. The handler stamps it onto the persisted entity as the modelUsed argument (ScoreEventSessionsHandler.cs:83), so a score row records both the number and its provenance.
  • PromptVersion { get; } (:30) exposes the version of the prompt contract the implementation sends, as a dated yyyy-MM-dd.N string, and the handler stamps it on the same call (ScoreEventSessionsHandler.cs:83). The doc comment (:18-29) is where the operating rule lives: bump it on any change to the system prompt, the user-prompt assembly (speaker formatting included), the redaction rules applied to submitted text, or the structured-output schema. It also records why the rule holds, that the golden evaluation suite pins the rendered prompt by hash per version, so an unbumped prompt change fails there rather than silently re-basing every score.
  • Scope: one session per call. Nothing on this interface batches, so the fan-out policy (sequential, one at a time) is the handler's decision rather than the port's.
• Why it's built this way - defining the port in Application lets the scoring use case be exercised with a fake scorer, and lets the AI vendor change without touching the handler. Exposing ModelId and PromptVersion on the port rather than hard-coding strings in the handler means the recorded provenance cannot drift from the client that actually made the call: the implementation that assembles the prompt is the one thing that can honestly name its version.
• Where it's used - constructor-injected into ScoreEventSessionsHandler (:20); implemented by AnthropicScoringService in production and FakeAiScoringService in the integration test host.

[Rubric §16, AI-Native Application Architecture] applies: this type is part of the AI session-scoring feature (a model call behind a port, versioned prompt and model, an evaluation gate, metered spend; ADR-111).

SessionScoringQueue

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Sessions.UseCases.DecisionSupport.ScoreEventSessions · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Sessions/UseCases/DecisionSupport/ScoreEventSessions/SessionScoringQueue.cs:34 · Level 2 · class (sealed)

• What it is - the bounded in-process implementation of ISessionScoringQueue: a 16-slot channel of SessionScoringWorkItem values plus a concurrent set of the events currently claimed, registered as a singleton and drained by one hosted worker.
• Depends on - ISessionScoringQueue, SessionScoringWorkItem (same file, :21), and SessionScoringEnqueueResult. External: System.Threading.Channels.Channel<T> and System.Collections.Concurrent.ConcurrentDictionary<TKey, TValue> (:1-3).
• Concept introduced - claim-then-write, and refuse rather than drop. Two mechanisms interlock here and both repay a close read.
  • Refuse rather than drop. The channel is created with BoundedChannelFullMode.Wait (:46) but is only ever written through the non-blocking TryWrite (:71, :97). That combination means a full queue makes TryWrite return false immediately instead of blocking the caller or evicting an older item. The doc comment states why the alternative is wrong for this workload: unlike an ephemeral live broadcast, a scoring run is expensive and the caller needs to know it was not accepted (:26-29). [Rubric §29 - Resilience & Business Continuity] assesses back-pressure policy; [Rubric §31 - Cost/FinOps] assesses spend control, since every accepted run is real money.
  • Claim first, then write. TryEnqueue adds to _pending before touching the channel (:68), so of two concurrent duplicate requests exactly one wins the TryAdd and the other is refused (:66-69). If the subsequent TryWrite fails, the claim is released again (:75) so a request that never queued cannot lock the event out. Taking the claim after a successful write would leave a window in which a second caller sees no claim and enqueues a duplicate.
  • SingleReader = true (:47) encodes that exactly one drain worker consumes the channel, so runs execute one at a time and cannot contend for the same event's rows (:30-31). SingleWriter = false (:48) admits many concurrent producers.
• Walkthrough
  • Capacity = 16 (:38), with the comment stating the intent: organizers score a handful of events, so the bound exists to refuse a runaway caller, not to absorb load (:36-37). FirstAttempt = 1 (:41) is the attempt number stamped on an item queued from an original request.
  • _channel (:43-49), the bounded channel described above; _pending (:55), a ConcurrentDictionary<EventIdentifierType, byte> used as a set. Its doc comment names the important subtlety: the drain removes an entry only after the run finishes, so the dedup window covers execution too, not just the wait in the queue (:51-54).
  • Reader (:58) exposes the ChannelReader<SessionScoringWorkItem> for the hosted drain. It is on the class, not on the interface, so only a consumer holding the concrete type can read.
  • IsPending(eventId) (:61) is a dictionary lookup.
  • TryEnqueue(eventId) (:64-77) returns AlreadyPending on a lost claim (:69), Queued on a successful write (:72), or QueueFull after releasing the claim (:75-76).
  • TryRequeue(eventId, attempt) (:93-103) is the retry path and deliberately does not refuse an already-claimed event: its caller is the drain worker itself, which has just finished the run that held the claim, so re-adding is the point rather than a duplicate (:83-89). A full channel is handled exactly as on the enqueue path, by giving the claim back (:100-102).
  • MarkCompleted(eventId) (:110) clears the claim once a run has finished, successfully or not.
• Why it's built this way - the dedup guarantee is only as good as the ordering of the claim and the write, and the two release paths exist so that a refusal never leaves a permanent phantom claim behind. Note what the class does not try to be: durable. It is in-process memory, so a replica restart loses queued items, which is why SessionScoringSweepJob exists as a slower crash-recovery backstop (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Infrastructure/Sessions/Scoring/SessionScoringSweepJob.cs:10-20).
• Where it's used - registered twice on purpose: TryAddSingleton<SessionScoringQueue>() and then TryAddSingleton<ISessionScoringQueue>(sp => sp.GetRequiredService<SessionScoringQueue>()), so both registrations resolve to the one instance (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/DependencyInjection.cs:64-65; the comment at :57-60 notes that producers would otherwise write to a queue nobody drains). Producers hold the interface; SessionScoringProcessor holds the concrete class and uses Reader, MarkCompleted, and TryRequeue (SessionScoringProcessor.cs:50, :107, :135, :143). Exercised directly by SessionScoringQueueTests (MMCA.ADC/Tests/Modules/Conference/MMCA.ADC.Conference.Application.Tests/Sessions/DecisionSupport/SessionScoringQueueTests.cs:11).
• Caveats / not-in-source - dedup is per process. Conference runs with more than one replica, so two triggers landing on different replicas both pass this class's _pending check; the cross-replica guard is an IDistributedLock taken by the drain worker before it invokes the handler, and a host with no Redis configured falls back to per-replica exclusion again (SessionScoringProcessor.cs:162-188). Nothing here bounds how long a claim may live: MarkCompleted is the only release, so a consumer that neither completes nor crashes would hold an event's claim indefinitely.

[Rubric §16, AI-Native Application Architecture] applies: this type is part of the AI session-scoring feature (a model call behind a port, versioned prompt and model, an evaluation gate, metered spend; ADR-111).

GetSessionSelectionDashboardHandler

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Sessions.UseCases.DecisionSupport.GetSessionSelectionDashboard · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Sessions/UseCases/DecisionSupport/GetSessionSelectionDashboard/GetSessionSelectionDashboardHandler.cs:16 · Level 9 · class (sealed)

• What it is - the composite handler behind the session-selection screen. It validates the event, loads sessions, categories, speakers, and AI scores once, and computes five blocks from that one snapshot: summary counts, category distribution, speaker overlap, speaker locality, and per-session AI scores.
• Depends on - IQueryHandler<in TQuery, TResult> (implemented) and IUnitOfWork (the only constructor dependency, :16-17); the aggregates Event, Session, Speaker, Category, and SessionAiScore; SpeakerLocalityHelper and its LocalityLookupEntry; SessionStatuses; the nested StatusBucket; Result and Error; and the output contracts SessionSelectionDashboardDTO, CategoryDistributionDTO, SpeakerSessionOverlapDTO, MultiSessionSpeaker, SpeakerSessionSummary, SpeakerLocalitySummary, and SessionAiScoreDTO (:5).
• Concept introduced - one snapshot, many projections, and the deliberate query-filter escape. Two mechanisms are worth learning here. The first is the load-once discipline: the comment at :33 records that the loads stay sequential for EF single-context safety (a DbContext is not thread-safe, so "parallel-friendly" here means ordered and independent, not concurrent), and every later block is a pure function over the already-materialized collections. The second is the one place the handler steps outside the framework's defaults: the speaker load passes ignoreQueryFilters: true (:61), turning off the global soft-delete filter for that read only. The comment above it explains the rule (:52-56): speaker deletion deliberately does not cascade to SessionSpeaker links (BR-70/BR-71), so a live link can point at a soft-deleted speaker, and honoring the filter would render that row as "Unknown" instead of the truth. [Rubric §8 - Data Architecture] assesses whether soft-delete semantics are applied deliberately rather than by reflex: this is an explicit, commented, single-read opt-out, and the comment notes that every downstream consumer re-filters the child collections in memory, so the escape cannot resurrect deleted category items. [Rubric §12 - Performance & Scalability] assesses request economy: five loads serve five projections. [Rubric §15 - Best Practices & Code Quality] assesses duplication, and that is the honest weak point (see the caveats).
• Walkthrough - HandleAsync (:19-122) resolves four repositories (:23-26), then fetches the Event and returns Error.NotFound decorated with source and target when it is missing (:29-31): this is the only decision-support handler with a failure path, pinned by HandleAsync_WhenEventNotFound_ReturnsNotFound (MMCA.ADC/Tests/Modules/Conference/MMCA.ADC.Conference.Application.Tests/Sessions/UseCases/DecisionSupport/GetSessionSelectionDashboardHandlerTests.cs:198). It loads the event's non-service sessions with SessionSpeakers and SessionCategoryItems included, untracked (:34-38), all categories with their items (:40-43), the distinct speaker ids referenced by live session-speaker links (:46-50), and those speakers with SpeakerCategoryItems included and query filters off (:57-62), indexed into a dictionary (:63). Two lookups follow: category-item id to name (:66-73) and the locality lookup built by SpeakerLocalityHelper from the locality categories it finds (:75-76). The summary counts are four Count passes plus one subtraction: accepted counts null-or-Accepted statuses, accept-queue and declined count their constants, and pending is the remainder (:79-86). ComputeCategoryDistribution (:89, :124-131) reuses the same tally-then-group shape as GetCategoryDistributionHandler, via CountCategoryItems (:133-156) and BuildCategoryGroups (:158-184). ComputeSpeakerOverlap (:92, :186-253) groups sessions by live speaker link, skips ids missing from the lookup (:213-214), stamps each speaker's locality tier (:224), orders each speaker's sessions by title (:227), and sorts speakers by session count descending, then accepted-session presence, then name (:240-250). ComputeSpeakerLocality (:95, :255-312) re-groups the same sessions by speaker, resolves each speaker to a tier defaulting to "Unknown" (:283-287), accumulates speaker, session, accepted, and accept-queue counts per tier in a case-insensitive dictionary (:279, :289-299), and emits SpeakerLocalitySummary rows ordered by speaker count descending (:302-311). Finally the AI-score block loads every SessionAiScore whose SessionId is in the loaded set (:98-104), and BuildAiScoreDtos (:337-360) orders them by OverallScore descending and projects each one through BuildSingleAiScoreDto (:362-393). That projection copies the score's provenance straight through, ModelUsed and PromptVersion (:385-386), so the screen can attribute a number to the model and the prompt contract behind it. It is also where the "Level" category is special-cased: the handler finds the first non-deleted category whose title contains "Level" (:347-348), collects its item ids (:349-351), and ResolveCategoryInfo (:411-433) then splits a session's tags into ordinary categories and the single level value. ResolveSpeakerLocalities (:395-409) produces the distinct tier names for a scored session's speakers, again defaulting to "Unknown". ScoredOn prefers LastModifiedOn and falls back to CreatedOn (:387), the audit fields the framework stamps on save.
• Why it's built this way - the screen needs internally consistent numbers, and computing every block from one materialized snapshot is what guarantees the speaker panel and the category panel describe the same set of sessions. The AI scores are read here rather than computed here because scoring is background work: ScoreEventSessionsHandler does the writing off the request path and the dashboard surfaces whatever rows exist, which is why the queue endpoint tells the caller to refresh after a few minutes (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.API/Controllers/Sessions/SessionSelectionController.cs:96-100).
• Where it's used - injected into SessionSelectionController as IQueryHandler<GetSessionSelectionDashboardQuery, Result<SessionSelectionDashboardDTO>> (SessionSelectionController.cs:31) and invoked from GET SessionSelection/dashboard/{eventId} (:39-51), the one decision-support endpoint the Blazor UI calls, through SessionSelectionService (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Services/Sessions/Selection/SessionSelectionService.cs:14-32) and onto the SessionSelectionDashboard page.
• Caveats / not-in-source - the category-distribution and speaker-overlap logic is duplicated rather than shared: CountCategoryItems and BuildCategoryGroups here (:133-156, :158-184) mirror GetCategoryDistributionHandler's equivalents, and ComputeSpeakerOverlap (:186-253) mirrors GetSpeakerSessionOverlapHandler's BuildMultiSessionSpeakers. Nothing in source keeps the copies aligned, and they already differ in one visible way: this handler loads speakers with ignoreQueryFilters: true (:61) while the standalone overlap handler does not (GetSpeakerSessionOverlapHandler.cs:41-45), so a soft-deleted speaker appears on the dashboard and is absent from the narrow endpoint. The "Level" category is matched by a substring of the category title (:347-348), so renaming that category upstream silently empties SessionLevel. A session carrying more than one level tag resolves to whichever ResolveCategoryInfo encounters first (:427-430), decided by the enumeration order of the session's links. The handler resolves the read-write GetRepository for all five entity types (:23-26, :98) although it only reads: IUnitOfWork exposes a narrower GetReadRepository alongside it (MMCA.Common/Source/Core/MMCA.Common.Application/Interfaces/Infrastructure/Persistence/IUnitOfWork.cs:19 versus :29).

GetSpeakerSessionOverlapHandler

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Sessions.UseCases.DecisionSupport.GetSpeakerSessionOverlap · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Sessions/UseCases/DecisionSupport/GetSpeakerSessionOverlap/GetSpeakerSessionOverlapHandler.cs:18 · Level 9 · class (sealed)

• What it is - the query handler that returns every speaker who submitted at least one session for an event, each with their sessions and locality tier, sorted so speakers holding several proposals appear first.
• Depends on - IQueryHandler<in TQuery, TResult> (implemented) and IUnitOfWork (the only constructor dependency, :18-19); the aggregates Session, Speaker, and Category plus the SessionSpeaker and SpeakerCategoryItem links; SpeakerLocalityHelper and LocalityLookupEntry; SessionStatuses; and the output contracts SpeakerSessionOverlapDTO, MultiSessionSpeaker, and SpeakerSessionSummary (:4).
• Concept introduced - inverting an aggregate's direction in memory. The database is queried session-first (sessions for an event, with their speaker links included, :29-33), but the answer is speaker-first. GroupSessionsBySpeaker (:61-82) performs that inversion: it flattens sessions into (SpeakerId, Session) pairs while skipping soft-deleted links (:64-67) and folds them into a dictionary of speaker to session list. Only then does the handler know which speakers to fetch, which is why the Speaker load is a GetByIdsAsync over the collected keys (:41-45, the interface at MMCA.Common/Source/Core/MMCA.Common.Application/Interfaces/Infrastructure/Persistence/IRepository.cs:48) rather than a second broad query. [Rubric §12 - Performance & Scalability] assesses query shape: three loads, no per-speaker round trip, and an early return that skips the speaker and category loads entirely when the event has no sessions (:38-39), a path pinned by HandleAsync_WithNoSessions_ReturnsEmptyAndSkipsSpeakerLookup (MMCA.ADC/Tests/Modules/Conference/MMCA.ADC.Conference.Application.Tests/Sessions/UseCases/DecisionSupport/GetSpeakerSessionOverlapHandlerTests.cs:131). [Rubric §4 - DDD] assesses whether a concept is read from the aggregates the domain actually has: a speaker's origin is not a column but a category assignment, resolved by SpeakerLocalityHelper (:52-53, :119). [Rubric §6 - CQRS & Event-Driven] applies as for the sibling reads: a pure query with no failure path.
• Walkthrough - HandleAsync (:21-59) resolves session, speaker, and category repositories (:25-27), loads the event's non-service sessions with SessionSpeakers and SessionCategoryItems included and asTracking: false (:29-33), inverts them into the speaker-to-sessions dictionary (:35), and returns an empty SpeakerSessionOverlapDTO when no speaker was referenced (:38-39). Otherwise it loads exactly those speakers with SpeakerCategoryItems included (:41-45) and all categories with their items (:47-50), then builds two lookups: the locality lookup, via SpeakerLocalityHelper.BuildLocalityLookup(SpeakerLocalityHelper.FindLocalityCategories(categories)) (:52-53), and category-item id to name (:54, :84-97). BuildMultiSessionSpeakers (:99-140) walks the loaded speakers, skips any with no sessions in the dictionary (:108-109), computes HasAcceptedSession by treating a null status or SessionStatuses.Accepted as accepted with OrdinalIgnoreCase (:111-113), stamps the locality tier (:119), and orders each speaker's sessions by title case-insensitively (:122). Each session becomes a SpeakerSessionSummary through BuildSessionSummary (:142-153), which carries id, title, raw status, and the names of the session's non-deleted category items. The final sort (:127-137) is three-level: session count descending, then accepted-session presence, then speaker name with OrdinalIgnoreCase, which is what makes the list deterministic rather than dictionary-enumeration order.
• Why it's built this way - the class summary states the scope decision explicitly (:11-17): the endpoint returns every speaker, not only multi-session ones, because the UI renders a session-count column and lets the organizer see the whole roster while the sort surfaces the overlap cases first. Filtering server-side to speakers with two or more sessions would have made that same screen impossible without a second call.
• Where it's used - injected into SessionSelectionController as IQueryHandler<GetSpeakerSessionOverlapQuery, Result<SpeakerSessionOverlapDTO>> (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.API/Controllers/Sessions/SessionSelectionController.cs:33) and invoked from GET SessionSelection/speaker-overlap/{eventId} (:67-79). The Blazor UI does not call this endpoint: it reads the equivalent block off the dashboard response instead.
• Caveats / not-in-source - the type and method names are residue from the narrower original scope: the DTO element is still MultiSessionSpeaker and the builder is still BuildMultiSessionSpeakers (:99) even though single-session speakers are included (HandleAsync_IncludesSingleSessionSpeakers, GetSpeakerSessionOverlapHandlerTests.cs:174). Unlike GetSessionSelectionDashboardHandler, this handler's GetByIdsAsync call does not pass ignoreQueryFilters (:41-45, versus GetSessionSelectionDashboardHandler.cs:57-62), so the global soft-delete filter applies and a soft-deleted speaker is skipped along with every session only they submitted (HandleAsync_SkipsSpeakersMissingFromRepository, GetSpeakerSessionOverlapHandlerTests.cs:217). Whether that difference is intended is not stated in either file. LocalityCategory stays null when a speaker has no locality assignment (:119); this handler does not substitute "Unknown" the way the dashboard's locality block does.

ScoreEventSessionsHandler

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Sessions.UseCases.DecisionSupport.ScoreEventSessions · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Sessions/UseCases/DecisionSupport/ScoreEventSessions/ScoreEventSessionsHandler.cs:18 · Level 9 · class (sealed, partial)

• What it is - the use case that walks an event's sessions one at a time, asks the AI scorer about each, and persists each score the moment it arrives, returning how many were scored and how many failed.
• Depends on - IUnitOfWork, IAiScoringService, and ILogger<ScoreEventSessionsHandler> by primary constructor (:18-21); Session, Speaker, and SessionAiScore from the domain; ScoreEventSessionsResultDTO as the payload; Result and Error. It implements ICommandHandler<in TCommand, TResult> (:21).
• Concept introduced - incremental commit, and per-item replacement instead of an up-front wipe. This handler is the clearest example in the group of a long-running use case designed around the question "what does a run that dies halfway leave behind?".
  • Commit per session, not per run. SaveChangesAsync is called inside the loop (:108), so the UI can show real-time progress and a run killed at session 40 of 200 leaves 40 durable scores. That is the opposite of the usual one-transaction-per-command shape, and the summary says so explicitly (:12-17).
  • Replace in the same step that writes. The comment at :94-103 records the failure this design fixes: an up-front bulk delete of the event's scores made the dashboard reset to zero and count up, but it paid for that with every existing score on the event, so the first Anthropic call to fail on an expired key or a rate limit left the sessions it never reached with no score at all. Per-session granularity means a run that dies partway through has replaced only what it re-scored, and a session whose call failed keeps the score it already had. The delete-then-add pair is safe because the unique, soft-delete-filtered index on SessionId in SessionAiScoreConfiguration permits at most one live row per session either way (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Infrastructure/Persistence/EntityConfiguration/Sessions/SessionAiScoreConfiguration.cs:66-68).
  • [Rubric §8 - Data Architecture] assesses write granularity and the invariants the schema itself enforces; [Rubric §29 - Resilience & Business Continuity] assesses partial-failure behavior; [Rubric §31 - Cost/FinOps] assesses paid-call economy, since every failure that forces a full re-run costs money again; [Rubric §13 - Observability & Operability] assesses run legibility, which here is six source-generated [LoggerMessage] methods carrying progress counters (:138-154).
• Walkthrough
  • Repositories for Session and SessionAiScore off the unit of work (:27-28).
  • Load the event's sessions with SessionSpeakers included, excluding service sessions, asTracking: false (:30-34). An event with no sessions short-circuits to a success carrying zeroes (:36-37), not a failure.
  • Batch-load speakers: flatten SessionSpeakers, drop soft-deleted links, distinct the speaker ids, one GetByIdsAsync (:40-50), then a dictionary by id (:51). This is the N+1 avoidance step: one speaker query for the whole event rather than one per session.
  • The loop (:59-118). Per session: project the non-deleted speaker links into SpeakerInfo values, skipping ids the lookup does not resolve (:61-67); build a SessionScoringInput (:69); call ScoreSessionAsync (:70).
  • Two failure gates before any write. !result.Success counts a failure and continues (:72-77). SessionAiScore.Create returning a failure (an out-of-range score, MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Domain/Sessions/SessionAiScore.cs:171-178) also counts a failure and continues (:85-90), so a model that answers with a 12 is rejected at the domain boundary rather than persisted. The Create call passes both provenance values off the port, aiScoringService.ModelId and aiScoringService.PromptVersion (:79-83), so the persisted row names the model and the prompt contract that produced the number.
  • The write step (:92-117): ExecuteDeleteAsync for this session's existing score rows, accumulating the count into replaced (:105); AddAsync for the new entity (:107); SaveChangesAsync (:108). It is wrapped in catch (Exception ex) when (ex is not OperationCanceledException) (:113), so a save failure counts as one failed session and the loop continues, while a cancellation still propagates and unwinds the run.
  • Outcome (:120-135): log the replaced count if any, log the totals, then one policy decision. If nothing scored and something failed, return a Result failure with code AiScoring.AllFailed naming the likely cause (:127-133). Any partial success returns Result.Success with the counts, which is what keeps the drain worker from retrying a business outcome.
• Why it's built this way - the run is long, paid, and externally fallible, so the design optimizes for "every session that was successfully scored stays scored" over transactional all-or-nothing. The AllFailed failure exists so that a total washout (an expired key, a wrong endpoint) is loud rather than a silent success reporting zero.
• Where it's used - resolved by SessionScoringProcessor inside a per-run DI scope and invoked with a ScoreEventSessionsCommand (SessionScoringProcessor.cs:190-193). No controller calls it directly; the HTTP surface only enqueues. Behavior is pinned by ScoreEventSessionsHandlerTests (MMCA.ADC/Tests/Modules/Conference/MMCA.ADC.Conference.Application.Tests/Sessions/UseCases/DecisionSupport/ScoreEventSessionsHandlerTests.cs:13).
• Caveats / not-in-source - ExecuteDeleteAsync is a set-based database delete that bypasses change tracking, domain events, audit stamps, and soft-delete entirely (MMCA.Common/Source/Core/MMCA.Common.Application/Interfaces/Infrastructure/Persistence/IRepository.cs:419-429), so a replaced AI score is physically gone rather than flagged IsDeleted. Scoring is also strictly sequential, one Anthropic call at a time with no concurrency knob, so wall-clock time grows linearly with session count. The replaced counter is logged (:138-139) but is not part of ScoreEventSessionsResultDTO, which carries only SessionsScored and SessionsFailed.

[Rubric §16, AI-Native Application Architecture] applies: this type is part of the AI session-scoring feature (a model call behind a port, versioned prompt and model, an evaluation gate, metered spend; ADR-111).

ExportEventCalendarQuery

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Sessions.UseCases.ExportCalendar · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Sessions/UseCases/ExportCalendar/ExportEventCalendarQuery.cs:5 · Level 0 · record (sealed)

• What it is: the read request behind "add the whole conference to my calendar": one event id, answered with an RFC 5545 .ics document covering every exportable session on that event's schedule.
• Depends on: the EventIdentifierType alias, an int in this module (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Shared/MMCA.ADC.Conference.GlobalUsings.IdentifierType.cs:8). No other first-party types, nothing external.
• Concept introduced: the query whose result is a document, not a DTO. Every other read in this group resolves to a shaped DTO; this one resolves to Result<string> where the string is a complete calendar file (ExportEventCalendarHandler.cs:17). The query/handler split itself is taught by IQueryHandler<in TQuery, TResult> and is cross-referenced rather than re-taught. [Rubric §9, API & Contract Design] assesses whether a contract matches the representation its consumer needs: a calendar client wants text/calendar bytes, so the use case produces the serialized document and the controller only wraps it in a File(...) response (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.API/Controllers/Events/EventsController.cs:161-164). [Rubric §6, CQRS & Event-Driven] applies as for the sibling reads: a named message with no side effects, bound to exactly one handler by the generic argument.
• Walkthrough: one positional parameter, EventId (:5), documented by the summary and <param> above it (:3-4). No body, no defaults, no marker interface.
• Why it's built this way: the event-wide and single-session exports are genuinely different reads (one loads the whole schedule plus the room map, the other loads one session and then checks its parent), so they get separate messages instead of one query with a nullable session id. See ExportSessionCalendarQuery for the narrow twin.
• Where it's used: constructed by EventsController on GET Events/{id}/ics, an [AllowAnonymous] action under the EventsCache output-cache policy (EventsController.cs:154-165), resolved through the injected IQueryHandler<ExportEventCalendarQuery, Result<string>> (:54). The browser-side caller is the add-to-calendar button on PublicEventDetail (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Pages/Public/PublicEventDetail.razor:27-28).
• Caveats / not-in-source: the doc comment tags the feature "ADR-042 Wave 5" (:3). ADR-042 is the MAUI device-capability abstraction (Website/docs-src/adr/042-device-capability-abstraction.md:1) and says nothing about iCalendar, so read that tag as a delivery-wave label rather than as a pointer to a specification of this export.

ExportSessionCalendarQuery

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Sessions.UseCases.ExportCalendar · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Sessions/UseCases/ExportCalendar/ExportSessionCalendarQuery.cs:5 · Level 0 · record (sealed)

• What it is: the read request for a single-session .ics document, the one behind the "add to calendar" button on a session page.
• Depends on: the SessionIdentifierType alias, an int in this module (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Shared/MMCA.ADC.Conference.GlobalUsings.IdentifierType.cs:15). Nothing else.
• Concept: none new; it is the same document-producing read message as ExportEventCalendarQuery, which teaches the shape. [Rubric §5, Vertical Slice] assesses feature cohesion: both queries, both handlers, and the mapper they share sit in one ExportCalendar folder, so the whole capability is one directory.
• Walkthrough: one positional parameter, SessionId (:5), with the summary and <param> above it (:3-4).
• Why it's built this way: the single-session export is what a public attendee actually uses while browsing the agenda, and it enforces a stricter rule than the event export does (the session itself must be exportable, not merely present in a published event). Keeping it a separate message keeps that rule in one handler rather than as a branch inside a combined one.
• Where it's used: constructed by SessionsController on GET Sessions/{id}/ics, [AllowAnonymous] under the SessionsCache policy (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.API/Controllers/Sessions/SessionsController.cs:261-272), through the injected IQueryHandler<ExportSessionCalendarQuery, Result<string>> (:52). The UI caller is the add-to-calendar button on PublicSessionDetail (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Pages/Public/PublicSessionDetail.razor:38-39).

GetPublicSessionCategoryItemFilterQuery

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Sessions.UseCases.GetPublicSessionCategoryItemFilter · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Sessions/UseCases/GetPublicSessionCategoryItemFilter/GetPublicSessionCategoryItemFilterQuery.cs:8 · Level 0 · record (sealed)

• What it is: a parameterless marker query asking for the filter that limits SessionCategoryItem junction rows to those whose parent session is publicly visible. The whole type is one line: public sealed record GetPublicSessionCategoryItemFilterQuery; (GetPublicSessionCategoryItemFilterQuery.cs:8).
• Depends on: nothing first-party, nothing external. It is an empty record with no positional parameters.
• Concept: none new. The marker-query shape is taught under GetPublicSessionFilterQuery, the junction dimension under GetPublicSessionSpeakerFilterQuery, and the visibility rule itself lives once in PublicConferenceVisibility. The doc comment (:3-7) names the leak the query closes: a junction row is readable only when its parent session is publicly visible (the BR-49 status allow-list, inside a BR-108 published event), because otherwise the join endpoints would list the categories of a hidden session and so reveal that the session exists. [Rubric §11, Security] assesses whether an anonymous surface can be used to infer the existence of content the caller may not read; a join table is exactly the surface that gets forgotten once the parent entity is locked down.
• Walkthrough: no members. Note what is deliberately absent: unlike GetSessionsBySpeakerFilterQuery, which carries the speaker it filters by, this query takes no argument at all, because the junction reads carry no scope to narrow to. Every line of behavior lives in GetPublicSessionCategoryItemFilterHandler.
• Why it's built this way: the rule belongs to the parent session, not to the join row, so the query carries no arguments and the handler derives its answer from the shared resolver instead of restating BR-49 a second time.
• Where it's used: handled by GetPublicSessionCategoryItemFilterHandler; injected into SessionCategoryItemsController as an IQueryHandler<...> constructor parameter (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.API/Controllers/Sessions/SessionCategoryItemsController.cs:52) and constructed inside that controller's GetReadSpecificationAsync override (SessionCategoryItemsController.cs:73-83), which returns null for privileged readers (:76-77) and the specification for everyone else (:79-82). That override is the framework's read hook, so all four anonymous reads inherit the scope from one place: the unpaged list (:85-88), the paged list (:95-98), the lookup (:114-117), and the by-id read (:122-125), where a hidden parent session turns the row into a 404 rather than a redacted record.

GetPublicSessionFilterQuery

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Sessions.UseCases.GetPublicSessionFilter · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Sessions/UseCases/GetPublicSessionFilter/GetPublicSessionFilterQuery.cs:11 · Level 0 · record (sealed)

• What it is: the request for the BR-132 / BR-49 public-session filter, the single definition of "which sessions may a non-privileged caller see". The type is one line with no members: public sealed record GetPublicSessionFilterQuery; (GetPublicSessionFilterQuery.cs:11).
• Depends on: nothing first-party, nothing external. Its whole payload is its identity as a message type.
• Concept introduced: the marker query whose answer is a filter, not rows. Most read slices in this chapter return DTOs, and the calendar pair above returns a document. This family returns a Specification<TEntity, TIdentifierType>, a reusable predicate object the caller composes with its own paging, sorting, and filters before a single row is fetched. That indirection is what lets one visibility rule serve four different endpoint shapes (list, paged list, lookup, by-id) without any of them restating it. The query needs no members because the rule takes no parameters: it is the same rule for every caller who is not privileged. [Rubric §11, Security] assesses whether an authorization rule is enforced once, server side, on every path that can reach the data. The doc comment (:3-10) spells out the rule and why it is an allow-list rather than a deny-list: Accepted-or-unset sessions whose parent event is published, so a session in any other state (waitlisted, nominated, queued, declined, or an unrecognized Sessionize value) is invisible by default. A deny-list would silently expose the next status Sessionize invents. [Rubric §2, Design Patterns] assesses whether a recognized pattern is used where it earns its keep. Specification-as-return-value keeps the predicate composable: SessionsController ANDs it with the speaker filter rather than choosing between them (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.API/Controllers/Sessions/SessionsController.cs:127-129).
• Walkthrough: no members, no methods, no validation. The doc comment (:6-9) also records the physical constraint that shapes the handler: the design treats Session and Event as potentially living in different data sources, so the published-event check cannot be a navigation join and the handler delegates to the framework's cross-source specification helper.
• Why it's built this way: an empty record still buys a distinct type, and a distinct type is what the CQRS pipeline dispatches on. new GetPublicSessionFilterQuery() selects GetPublicSessionFilterHandler through the module's Scrutor scan, services.ScanModuleApplicationServices<ClassReference>() (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/DependencyInjection.cs:133, the strategy documented at :43-44), which registers every implementation of IQueryHandler<in TQuery, TResult> in the module assembly with a scoped lifetime (MMCA.Common/Source/Core/MMCA.Common.Application/DependencyInjection.cs:246-250). The visibility rule is therefore reached the same way every other read is, with the same decorators around it.
• Where it's used: handled by GetPublicSessionFilterHandler; injected into SessionsController (SessionsController.cs:51) and constructed in that controller's GetReadSpecificationAsync override (SessionsController.cs:77-87), which short-circuits to null for privileged readers (:79-80). That hook feeds the unpaged list (:148), the paged list through BuildPagedSessionSpecificationAsync (:110, applied at :187), the lookup (:213-216), and the by-id read (:225-231), each of which is [AllowAnonymous] (:136, :162, :211, :223) under the class-level [HasPermission(ConferencePermissions.SessionsManage)] (:43).
• Caveats / not-in-source: the doc comment states that Session lives in Cosmos DB and Event in SQL Server (:7-8), and the controller repeats it (SessionsController.cs:66-68). In ADC as configured today both are SQL Server entities: SessionConfiguration derives from EntityTypeConfigurationSQLServer<Session, SessionIdentifierType> (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Infrastructure/Persistence/EntityConfiguration/Sessions/SessionConfiguration.cs:12-13) and EventConfiguration from the same SQL Server base (.../EntityConfiguration/EventConfiguration.cs:11-12). The cross-source treatment is therefore prophylactic against the polyglot option (ADR-018) rather than a description of the deployed engine split.

GetPublicSessionSpeakerFilterQuery

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Sessions.UseCases.GetPublicSessionSpeakerFilter · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Sessions/UseCases/GetPublicSessionSpeakerFilter/GetPublicSessionSpeakerFilterQuery.cs:8 · Level 0 · record (sealed)

• What it is: the marker query for the filter that limits SessionSpeaker junction rows to those whose parent session is publicly visible. One line, no members (GetPublicSessionSpeakerFilterQuery.cs:8).
• Depends on: nothing first-party, nothing external.
• Concept introduced: visibility propagates down a junction. The marker shape itself comes from GetPublicSessionFilterQuery; what this query adds is the observation that hiding an entity is not finished until every table pointing at it is hidden too. The doc comment (:3-7) states the leak in one sentence: without this filter the join endpoints would list the speakers of a hidden session and thereby leak its existence. [Rubric §11, Security]: the junction is an independent read surface with its own controller and its own anonymous actions, so it needs its own enforcement rather than inheriting one.
• Walkthrough: no members. The filter is derived, not parameterized, so GetPublicSessionSpeakerFilterHandler can compute the answer from the same visible-session id list the category-item filter uses.
• Why it's built this way: giving the join its own query type (rather than reusing GetPublicSessionFilterQuery and translating the result) keeps each handler's return type bound to the entity being filtered: this one yields Specification<SessionSpeaker, SessionSpeakerIdentifierType>, which the join controller returns straight from the framework read hook with no adaptation.
• Where it's used: handled by GetPublicSessionSpeakerFilterHandler; injected into SessionSpeakersController (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.API/Controllers/Sessions/SessionSpeakersController.cs:52) and constructed in that controller's GetReadSpecificationAsync override (SessionSpeakersController.cs:73-83, privileged short circuit at :76-77). The hook feeds the unpaged list (:85-88), the paged list (:95-98), the lookup (:114-117), and the by-id read (:122-125), all [AllowAnonymous] (:86, :96, :115, :123) beneath the class-level [HasPermission(ConferencePermissions.SessionsManage)] (:47).

GetSessionsBySpeakerFilterQuery

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Sessions.UseCases.GetSessionsBySpeakerFilter · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Sessions/UseCases/GetSessionsBySpeakerFilter/GetSessionsBySpeakerFilterQuery.cs:11 · Level 0 · record (sealed)

• What it is: the one member of this filter family that carries an argument: public sealed record GetSessionsBySpeakerFilterQuery(SpeakerIdentifierType SpeakerId); (GetSessionsBySpeakerFilterQuery.cs:11). Its answer is the specification selecting the sessions a given speaker presents.
• Depends on: the SpeakerIdentifierType alias (System.Guid in Conference, MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Shared/MMCA.ADC.Conference.GlobalUsings.IdentifierType.cs:19). Nothing else.
• Concept introduced: the virtual filter key. A client filtering the paged session list by speaker sends SpeakerId as an ordinary filter key, but Session has no SpeakerId column: the link lives in the SessionSpeaker join. The doc comment (:4-9) records the resolution: the link is resolved as an ID-list projection so the resulting criteria stays engine-portable and the Session aggregate keeps a by-id boundary to Speaker, following the GetSpeakersByEventFilterQuery precedent (BR-132). [Rubric §4, DDD] assesses whether aggregates reference each other by identifier instead of by object graph; this query exists precisely so a cross-aggregate question can be answered without giving Session a navigation to Speaker. [Rubric §9, API & Contract Design]: the key is intercepted in the controller and never forwarded to the generic filter pipeline, which rejects unknown properties, and an unparseable value ignores the key rather than failing the request (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.API/Controllers/Sessions/SessionsController.cs:95-99, :112-117).
• Walkthrough: a single positional member, SpeakerId (:11), documented as the speaker whose sessions should match (:10). No behavior; all of it is in GetSessionsBySpeakerFilterHandler.
• Why it's built this way: modelling the answer as a specification (rather than as a list of sessions) lets the endpoint keep its generic list-page-sort machinery and simply AND one more criterion into it, which is exactly what the paged action does.
• Where it's used: handled by GetSessionsBySpeakerFilterHandler; injected into SessionsController (SessionsController.cs:52) and constructed in BuildPagedSessionSpecificationAsync after the SpeakerId key is removed from the filter dictionary and parsed (SessionsController.cs:113-121). The two specifications are ANDed, never substituted (:126-128); the remark at :100-104 states why: dropping the public filter for a speaker-scoped request would leak non-accepted sessions to non-privileged callers.

CalendarExportMapper

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Sessions.UseCases.ExportCalendar · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Sessions/UseCases/ExportCalendar/CalendarExportMapper.cs:14 · Level 9 · class (static, internal)

• What it is: the shared rules of the calendar export: which sessions may appear in one, how a session becomes an IcsEvent, and how an event-local wall-clock time becomes a UTC instant.
• Depends on: Session, Event, and SessionStatuses from the Conference domain, and IcsEvent from MMCA.Common.Shared.Calendars (:1-4). External: System.Globalization and BCL TimeZoneInfo.
• Concept introduced: the time-zone conversion contract, and one source of truth for a visibility allow-list.
  • IcsCalendarBuilder is UTC-only by contract so it can emit Z-suffixed timestamps and skip RFC 5545's VTIMEZONE machinery entirely (MMCA.Common/Source/Core/MMCA.Common.Shared/Calendars/IcsEvent.cs:3-8). Session times, however, are wall-clock local to the event's IANA zone. Somebody has to convert, and this mapper is where that happens, with the DST discipline stated in its own summary: invalid spring-forward times shift ahead one hour, ambiguous fall-back times resolve to the standard offset (:9-12). [Rubric §15, Best Practices & Code Quality] assesses whether a known-hard problem is handled explicitly rather than by accident: the two DST edge cases are named in the doc and the first is coded.
  • IsExportable delegates the status question wholesale to SessionStatuses.IsEligible, and the comment records why: this file used to carry a second, drifting copy of the allow-list (:21-22). [Rubric §11, Security] assesses whether a public-visibility rule has exactly one definition; a duplicated allow-list is how a status ends up publicly visible on one surface and not another.
• Walkthrough
  • ProductId = "-//MMCA//AtlDevCon//EN" (:17), the RFC 5545 PRODID stamped on every ADC-produced calendar document.
  • IsExportable(Session) (:26-28): a property pattern requiring StartsAt and EndsAt to be non-null and IsServiceSession to be false, combined with SessionStatuses.IsEligible(session.Status) (BR-49: only Accepted or an unset status, MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Domain/Sessions/SessionStatuses.cs:54-56). The summary states the deliberate design point: this is role-independent, because the ICS document is a public-schedule artifact, so privileged callers get the same filtered export (:23-24).
  • ToIcsEvent(Session, Event, TimeZoneInfo, string? roomName) (:31-44): joins the room name and the event's VenueAddress with ", ", dropping blanks (:33-35), then builds the IcsEvent with a stable uid of the form session-{id}@atldevcon (:38), the title, both converted instants (:40-41), the description, and the joined location or null when empty (:43). The stable uid matters: calendar apps use it to de-duplicate re-imports (MMCA.Common/Source/Core/MMCA.Common.Shared/Calendars/IcsEvent.cs:9), so re-downloading the file updates the entry instead of creating a second one.
  • ToUtc(DateTime localWallClock, TimeZoneInfo) (:47-56): re-kinds the input as Unspecified (:49), and if the zone reports it as an invalid time (the hour that does not exist on a spring-forward day) adds one hour (:50-53), then constructs the DateTimeOffset with that zone's offset for the adjusted instant (:55).
• Why it's built this way: both export handlers need identical filtering and identical time conversion. Putting them in an internal static class with no infrastructure dependencies means the rules are stated once, are unit-testable in isolation, and cannot diverge between the whole-schedule and single-session paths.
• Where it's used: by ExportEventCalendarHandler (ExportEventCalendarHandler.cs:44, :46, :53) and ExportSessionCalendarHandler (ExportSessionCalendarHandler.cs:27, :52-53).
• Testing: CalendarExportMapperTests (MMCA.ADC/Tests/Modules/Conference/MMCA.ADC.Conference.Application.Tests/Sessions/UseCases/ExportCalendar/CalendarExportMapperTests.cs:14) covers the predicate and the mapping separately: the eligible statuses as a theory (:41), a session with no start time (:45), statuses outside the allow-list as a theory (:63), a service session (:67), the wall-clock to UTC conversion (:72), the spring-forward shift (:82), the room-plus-venue location join (:96), venue only (:104), neither (:112), and the stable session-scoped uid (:120).
• Caveats / not-in-source: the summary says ambiguous fall-back times resolve to the standard offset, but no code branches on IsAmbiguousTime: that outcome comes from TimeZoneInfo.GetUtcOffset's own behavior for an ambiguous local time (:55), not from a decision in this file. IsExportable ignores the owning event's published state entirely; that check belongs to the callers, and both perform it.

GetSessionsBySpeakerFilterHandler

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Sessions.UseCases.GetSessionsBySpeakerFilter · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Sessions/UseCases/GetSessionsBySpeakerFilter/GetSessionsBySpeakerFilterHandler.cs:21 · Level 9 · class (sealed)

• What it is: the handler for GetSessionsBySpeakerFilterQuery. It projects the session ids linked to the speaker through the SessionSpeaker join and returns a Session.Id IN (...) filter (GetSessionsBySpeakerFilterHandler.cs:21-23).
• Depends on: IUnitOfWork (primary-constructor parameter, :22); IQueryHandler<in TQuery, TResult> closed over Result<Specification<Session, SessionIdentifierType>> (:23); InlineSpecification<TEntity, TIdentifierType> and Specification<TEntity, TIdentifierType>; Session and SessionSpeaker; Result.
• Concept introduced: ID-list projection instead of a navigation join. Rather than expressing the rule as one LINQ expression that walks Session -> SessionSpeaker -> Speaker, the handler runs a scalar projection query first and embeds its result in the predicate. GetProjectedAsync<TResult>(select, where, asTracking, ignoreQueryFilters, cancellationToken) returns only the selected column instead of whole entities; it is declared on the IEntityQuerier<TEntity, TIdentifierType> facet (MMCA.Common/Source/Core/MMCA.Common.Application/Interfaces/Infrastructure/Persistence/IRepository.cs:105-110, facet declared at :80) that IReadRepository<TEntity, TIdentifierType> composes (IRepository.cs:330-331). [Rubric §8, Data Architecture] assesses whether query shapes survive the storage topology the architecture allows. A navigation join is only translatable when both ends sit in the same physical source; an IN over materialized ids translates on every provider, which is what ADR-018 needs. The framework enforces the same constraint mechanically for declared specification classes through the SpecificationsDoNotNavigateToOtherEntities fitness rule, which instantiates parameterless specifications and inspects their Criteria (MMCA.Common/Source/Hosting/MMCA.Common.Testing.Architecture/Rules/Domain/ArchitectureRules.Specifications.cs:24, evaluation at :53, failure message at :74). [Rubric §4, DDD]: the class comment (:9-14) states the second property being bought, that the Session aggregate keeps its by-id boundary to the Speaker aggregate even while answering a cross-aggregate question.
• Walkthrough
  1. Project the linked session ids (:30-37): resolve the read repository for SessionSpeaker and call GetProjectedAsync(ss => ss.SessionId, ss => ss.SpeakerId == query.SpeakerId, asTracking: false, cancellationToken: cancellationToken). Nothing here will be mutated, so the untracked read is what is wanted; asTracking is passed explicitly even though false is already its default (IRepository.cs:108), and a tracked read would pollute the change tracker for whatever else the request does. ignoreQueryFilters is left at its false default (IRepository.cs:109), so soft-deleted join rows are excluded by the EF global query filter rather than by a predicate term written here.
  2. Materialize and de-duplicate (:39-40): IReadOnlyList<SessionIdentifierType> ids = [.. sessionIds.Distinct()];. The inline comment (:39) gives the reason for materializing: the predicate must embed a stable collection EF can translate to IN. A lazily-enumerated source would be captured unevaluated and re-enumerated every time the criteria is applied.
  3. Wrap and return (:42-43): ids.Contains(s.Id) becomes an InlineSpecification<TEntity, TIdentifierType> returned inside Result.Success. There is no failure path: the handler cannot fail on its own terms.
• Why it's built this way: the <para> in the class comment (:15-19) records the one behavior that is easy to get wrong downstream. A speaker with no sessions yields an empty id list, and an empty IN matches nothing, which is the correct answer; that is exactly why the caller must apply the specification rather than skip it when the list is empty. Skipping it would turn "this speaker presents nothing" into "show every session".
• Where it's used: SessionsController's BuildPagedSessionSpecificationAsync is the only consumer (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.API/Controllers/Sessions/SessionsController.cs:120-122), which ANDs the result with the public-session filter via AndSpecification<TEntity, TIdentifierType> (:126-128) and falls back to the public filter alone if this handler reports failure (:123-124).
• Testing: GetSessionsBySpeakerFilterHandlerTests (MMCA.ADC/Tests/Modules/Conference/MMCA.ADC.Conference.Application.Tests/Sessions/UseCases/GetSessionsBySpeakerFilter/GetSessionsBySpeakerFilterHandlerTests.cs:16), five tests on the shared HandlerTestBase<THandler>: the success shape (:60), a presented session matching (:69), a session the speaker does not present being excluded (:79), a speaker with no sessions matching nothing (:89), and repeated join rows collapsing to one id (:101, the Distinct() at :40).
• Caveats / not-in-source: the id list is materialized into the predicate, so the IN list grows with the number of sessions one speaker presents. That is naturally bounded for a conference speaker, but nothing in this file enforces a bound.

ExportEventCalendarHandler

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Sessions.UseCases.ExportCalendar · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Sessions/UseCases/ExportCalendar/ExportEventCalendarHandler.cs:15 · Level 10 · class (sealed)

• What it is: the read use case that turns a published event into one .ics document: every exportable session becomes one VEVENT with its room in the location field.
• Depends on: IUnitOfWork by primary constructor (:15-16), CalendarExportMapper, IcsCalendarBuilder, the Event and Session aggregates, and Result / Error. It implements IQueryHandler<ExportEventCalendarQuery, Result<string>> (:17).
• Concept introduced: trusting a write-side invariant on the read path. Time zones are validated on write by EventInvariants.EnsureTimeZoneIsValid (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Domain/Events/EventInvariants.cs:82), and this handler takes that guarantee at face value: TimeZoneInfo.FindSystemTimeZoneById(@event.TimeZone) is called bare, with no try and no fallback (:41). The comment above it states the policy in full: because the invariant guards every write path a stored id always resolves, so there is no fallback and an unresolvable id is a data defect that must surface (:39-40). [Rubric §29, Resilience & Business Continuity] assesses the degradation policy on a failure path. The choice here is deliberately not to degrade: silently exporting a schedule shifted into the wrong zone would hand attendees wrong times, so the handler prefers a loud failure over a plausible-looking wrong answer. [Rubric §11, Security] assesses information disclosure on an anonymous endpoint: an unpublished or unknown event returns Error.NotFound tagged with source and target (:28-32), so the response cannot distinguish "does not exist" from "not published yet".
• Walkthrough
  • Load the Event by id with nameof(Event.Rooms) included (:25-27). The comment explains the include rather than a separate repository call: rooms are children of the Event aggregate and have no repository of their own (:24), which is aggregate-boundary discipline in practice.
  • Guard: null or not IsPublished returns the NotFound error (:28-32).
  • Load every session for the event with no includes (:34-36), untracked by the repository default (MMCA.Common/Source/Core/MMCA.Common.Application/Interfaces/Infrastructure/Persistence/IRepository.cs:85-92, asTracking defaulting to false at :90), then build a room-id to room-name dictionary from the loaded rooms (:37).
  • Resolve the time zone with the no-fallback call described above (:39-41).
  • Project: filter by CalendarExportMapper.IsExportable (:44), order by StartsAt (:45), map each session through ToIcsEvent, passing the room name only when the session has a RoomId the dictionary resolves (:46-50).
  • Build and return: IcsCalendarBuilder.Build(CalendarExportMapper.ProductId, entries, DateTimeOffset.UtcNow) wrapped in Result.Success (:53-54).
• Why it's built this way: the filtering and conversion rules live in CalendarExportMapper, so this handler is only orchestration: load, guard, project, serialize. Ordering by StartsAt before serializing means the document reads chronologically for any client that renders it as a list, since IcsCalendarBuilder emits the entries in the order the caller supplies them (MMCA.Common/Source/Core/MMCA.Common.Shared/Calendars/IcsCalendarBuilder.cs:20, loop at :34-37).
• Where it's used: injected into EventsController as IQueryHandler<ExportEventCalendarQuery, Result<string>> (EventsController.cs:55), invoked from GET Events/{id}/ics (:160), which returns the string as a text/calendar file named event-{id}.ics (:163).
• Testing: ExportEventCalendarHandlerTests (MMCA.ADC/Tests/Modules/Conference/MMCA.ADC.Conference.Application.Tests/Sessions/UseCases/ExportCalendar/ExportEventCalendarHandlerTests.cs:16), three tests: an unknown event as NotFound (:61), an unpublished event as NotFound (:74), and a published event producing an ICS document with converted times (:87).
• Caveats / not-in-source: the handler loads every session on the event with no paging or cap, so document size scales with the schedule. DateTimeOffset.UtcNow is read inline rather than through an injected clock (:53), so the emitted DTSTAMP differs per call even though IcsCalendarBuilder is otherwise deterministic for identical inputs. A session whose RoomId is not among the event's loaded rooms exports silently with no room in its location. And per the policy above, a stored time-zone id the host cannot resolve throws TimeZoneNotFoundException out of this handler rather than degrading; nothing in this file catches it.

ExportSessionCalendarHandler

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Sessions.UseCases.ExportCalendar · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Sessions/UseCases/ExportCalendar/ExportSessionCalendarHandler.cs:16 · Level 10 · class (sealed)

• What it is: the read use case behind the single-session add-to-calendar button: one session, one VEVENT, one .ics document.
• Depends on: the same set as its event-wide twin: IUnitOfWork (:16-17), CalendarExportMapper, IcsCalendarBuilder, Session, Event, Result / Error. It implements IQueryHandler<ExportSessionCalendarQuery, Result<string>> (:18).
• Concept introduced: the two-hop public-read guard. The interesting difference from ExportEventCalendarHandler is that a session id alone does not establish public visibility: the session must itself be exportable and its owning event must be published. This handler checks both, in that order, and answers NotFound for either failure (:27-31, :37-41). The summary states the intent plainly: everything else is NotFound so the endpoint leaks nothing about unpublished content (:13-14). [Rubric §11, Security] assesses whether an anonymous endpoint can be used to probe for hidden content: a declined session and a session inside an unpublished event are indistinguishable from one that does not exist. [Rubric §1, SOLID] assesses reuse over duplication: the filtering rule itself is not restated here, it is the same IsExportable predicate the event-wide export applies.
• Walkthrough
  • Load the session by id, no includes (:25-26); guard on null or !CalendarExportMapper.IsExportable(session) (:27-31).
  • Load the owning Event with Rooms included via session.EventId (:34-36), with the same aggregate-child note as the twin (:33); guard on null or unpublished (:37-41).
  • Resolve the room name by scanning the event's loaded rooms for session.RoomId, null when the session has no room (:43-45).
  • Resolve the time zone with the same no-fallback call and the same comment recording why (:47-49).
  • Build a one-element calendar with a collection expression (:51-54) and return it as a success (:56).
• Why it's built this way: it is a deliberate near-twin of the event-wide handler rather than a shared code path with a nullable session id, because the guard order differs (session first, then event) and the room lookup is a scan rather than a dictionary. Everything genuinely shared, the export predicate, the PRODID, the IcsEvent mapping, and the time conversion, already lives once in CalendarExportMapper.
• Where it's used: injected into SessionsController as IQueryHandler<ExportSessionCalendarQuery, Result<string>> (SessionsController.cs:53), invoked from GET Sessions/{id}/ics (:267), which returns text/calendar named session-{id}.ics (:270).
• Testing: ExportSessionCalendarHandlerTests (MMCA.ADC/Tests/Modules/Conference/MMCA.ADC.Conference.Application.Tests/Sessions/UseCases/ExportCalendar/ExportSessionCalendarHandlerTests.cs:16), four tests that walk the two-hop guard: an unknown session (:53), a declined session (:66), a session inside an unpublished event (:79), and the success path returning an ICS document with the room in the location (:95).
• Caveats / not-in-source: as with the twin, DateTimeOffset.UtcNow is read inline (:54) rather than injected, and an unresolvable stored time-zone id throws out of the handler rather than degrading. The two time-zone resolutions in this folder are separate copies with nothing shared between them, so a change to that policy has to be made in both handlers.

GetPublicSessionFilterHandler

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Sessions.UseCases.GetPublicSessionFilter · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Sessions/UseCases/GetPublicSessionFilter/GetPublicSessionFilterHandler.cs:20 · Level 10 · class (sealed)

• What it is: the handler for GetPublicSessionFilterQuery and the definitive statement of BR-132 / BR-49 in code. It resolves the published Event ids and returns a Session.EventId IN (...) filter ANDed with the status allow-list (GetPublicSessionFilterHandler.cs:20-22).
• Depends on: IUnitOfWork (:21); CrossSourceSpecification; PublicSessionStatusSpecification (for its static StatusCriteria); Session and Event; Specification<TEntity, TIdentifierType>; Result; IQueryHandler<in TQuery, TResult> (:22).
• Concept introduced: composing a filter across two data sources. CrossSourceSpecification exists because a predicate like s => s.Event.IsPublished is not translatable when principal and dependent may live in different physical sources (MMCA.Common/Source/Core/MMCA.Common.Application/Specifications/CrossSourceSpecification.cs:9-21). BuildAsync runs a scalar projection against the principal's own source (:54-57), materializes the keys once (:59-60), then builds Enumerable.Contains(keys, dependent.ForeignKey) as an expression tree (:74-79) and ANDs the optional local predicate onto it after rebinding its parameter, deliberately avoiding Expression.Invoke so the combined predicate stays translatable on every provider (:66-91, the rebinding at :86-87). [Rubric §3, Clean Architecture] assesses whether infrastructure concerns stay out of the application layer. The handler expresses a business rule and hands the storage problem to a framework helper; it names no provider, no table, and no SQL. [Rubric §15, Best Practices & Code Quality]: the status leg is not written here. It is PublicSessionStatusSpecification's StatusCriteria (:34), the same static expression the visible-session id resolver passes (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Common/PublicConferenceVisibility.cs:68), so the session list and every derived read cannot drift apart. That expression is s => s.Status == null || s.Status == SessionStatuses.Accepted and compares against SessionStatuses.Accepted rather than calling SessionStatuses's IsEligible, because compiled code does not translate to SQL (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Sessions/Specifications/PublicSessionStatusSpecification.cs:12-19, :23-24).
• Walkthrough
  1. Build the cross-source specification (:29-36): one call to CrossSourceSpecification.BuildAsync<Session, SessionIdentifierType, Event, EventIdentifierType> with principalPredicate: e => e.IsPublished (BR-108), dependentForeignKey: s => s.EventId, and localPredicate: PublicSessionStatusSpecification.StatusCriteria (BR-49). The type arguments pin the direction of the relationship: Session is the dependent being filtered, Event the principal being resolved.
  2. Return (:38): Result.Success(specification). As with its siblings there is no failure branch.
• Why it's built this way: the whole handler is two statements because the reusable mechanics were pushed into the framework. What stays local is the pair of business predicates, which is the part that can change. The rule is enforced at the application layer rather than in the controller so that every caller of the query gets it, including the ones added later.
• Where it's used: SessionsController via its GetReadSpecificationAsync override (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.API/Controllers/Sessions/SessionsController.cs:77-87), which reaches the unpaged list, the paged list, the lookup, and the by-id read. The lookup action is worth reading: it is an attribute-only passthrough to the framework base action (SessionsController.cs:214-217) precisely because the read hook already scopes it, and a lookup endpoint would otherwise be a side channel listing the sessions the list and detail endpoints already hide (:204-208).
• Testing: GetPublicSessionFilterHandlerTests (MMCA.ADC/Tests/Modules/Conference/MMCA.ADC.Conference.Application.Tests/Sessions/UseCases/GetPublicSessionFilter/GetPublicSessionFilterHandlerTests.cs:12), seven test methods asserted against the produced criteria rather than against the handler's internals: the success shape (:72), the public statuses matching for a published event (:84, a theory over Accepted and null), the non-public statuses excluded (:101, a theory over the non-eligible Sessionize values), a session of an unpublished event excluded (:111), no published events matching nothing (:121), the principal predicate selecting only published events (:139), and the cancellation token reaching the event query (:162).
• Caveats / not-in-source: CrossSourceSpecification materializes the matching principal keys into the predicate, and its own note (CrossSourceSpecification.cs:17-20) scopes the technique to small or bounded principal sets, the "published events" shape. Nothing in this handler bounds that set; it is bounded in practice by how many events a conference publishes. Note also that the controller maps a failed Result to null, meaning no filter (SessionsController.cs:86), which would widen the read rather than narrow it; nothing in this handler can produce that failure today, so the exposure is latent rather than live.

GetPublicSessionCategoryItemFilterHandler

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Sessions.UseCases.GetPublicSessionCategoryItemFilter · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Sessions/UseCases/GetPublicSessionCategoryItemFilter/GetPublicSessionCategoryItemFilterHandler.cs:16 · Level 11 · class (sealed)

• What it is: the handler for GetPublicSessionCategoryItemFilterQuery. It asks PublicConferenceVisibility for the visible session ids and wraps them in a SessionCategoryItem.SessionId IN (...) specification (GetPublicSessionCategoryItemFilterHandler.cs:16-18).
• Depends on: IUnitOfWork (:17, injected only to hand on to the resolver); PublicConferenceVisibility; InlineSpecification<TEntity, TIdentifierType>; SessionCategoryItem; Result. Implements IQueryHandler<in TQuery, TResult> to Result<Specification<SessionCategoryItem, SessionCategoryItemIdentifierType>> (:18).
• Concept: none new; the derived junction filter is taught under GetPublicSessionSpeakerFilterHandler, and this is the category-assignment instance of the same shape. It calls the identical resolver method its speaker-side twin does and restates nothing of the rule. [Rubric §15, Best Practices & Code Quality]: the junction cannot drift away from the entity whose visibility it follows, because it holds no copy of that entity's rule. [Rubric §8, Data Architecture]: the answer arrives as an id list turned into Contains, not a navigation join, so the criteria stays translatable on any provider (ADR-018).
• Walkthrough
  1. Resolve the visible session ids (:25-27): PublicConferenceVisibility.GetVisibleSessionIdsAsync(unitOfWork, cancellationToken). Inside the resolver that is the same CrossSourceSpecification.BuildAsync call GetPublicSessionFilterHandler makes, over Session and Event with principalPredicate: e => e.IsPublished, dependentForeignKey: s => s.EventId, and localPredicate: PublicSessionStatusSpecification.StatusCriteria (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Common/PublicConferenceVisibility.cs:63-70). The resolver then hands that specification straight to the repository's spec-taking projection overload, ListAsync(specification, s => s.Id, cancellationToken) (PublicConferenceVisibility.cs:77-79; the overload is declared at MMCA.Common/Source/Core/MMCA.Common.Application/Interfaces/Infrastructure/Persistence/IRepository.cs:279-282 and projects server side, after the specification's ordering and paging, :264-273). The comment above the call explains why passing a specification is enough (PublicConferenceVisibility.cs:72-74): a plain specification contributes its Criteria and nothing else, so this is the untracked, soft-delete-filtered read the explicit GetProjectedAsync arguments would otherwise have to spell out. The comment at :61-62 states the property being bought: the same helper and the same criteria the public-session read filter uses, so a session hidden from the session list can never stay reachable through a junction read.
  2. Wrap and return (:29-31): sci => sessionIds.Contains(sci.SessionId) inside an InlineSpecification<TEntity, TIdentifierType>, returned as Result.Success. No failure path.
• Why it's built this way: the doc comment states the intent directly (:10-15): a junction row follows the visibility of its parent session (BR-49). Deriving that answer instead of copying the session rule keeps one definition of "publicly visible session" behind the session list, the session-speaker join, and this category-assignment join.
• Where it's used: SessionCategoryItemsController's GetReadSpecificationAsync override (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.API/Controllers/Sessions/SessionCategoryItemsController.cs:73-83) is the only consumer, and from there it reaches the unpaged list (:85-88), paged list (:95-98), lookup (:114-117), and by-id (:122-125) reads. Note that the class-level [HasPermission(ConferencePermissions.SessionsManage)] (:47) is overridden per action by [AllowAnonymous] (:86, :96, :115, :123), which is exactly why the handler has to carry the visibility rule itself.
• Testing: GetPublicSessionCategoryItemFilterHandlerTests (MMCA.ADC/Tests/Modules/Conference/MMCA.ADC.Conference.Application.Tests/Sessions/UseCases/GetPublicSessionCategoryItemFilter/GetPublicSessionCategoryItemFilterHandlerTests.cs:18), four tests on the shared HandlerTestBase<THandler>: the success shape (:56), a row whose parent session is visible (:65), a row whose parent session is hidden (:75), and a world with no visible sessions at all (:85). The fixture mocks the two reads the resolver actually performs: GetProjectedAsync on the Event repository (:29-36) and the spec-taking ListAsync on the Session repository (:46-51), whose comment notes that the resolver hands the session read a specification rather than an unwrapped predicate. One further detail is a property of the entity rather than of the test: SessionCategoryItem.SessionId is get-only and written by EF (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Domain/Sessions/SessionCategoryItem.cs:24), so a row built in memory carries the default id, and the fixture uses default as its row session id (:20-21).
• Caveats / not-in-source: as on the other junction reads, the controller maps a failed Result to null, meaning no filter (SessionCategoryItemsController.cs:82), which would widen the read rather than narrow it; nothing in this handler can produce that failure today, so the exposure is latent rather than live. The resolved id list is also materialized into the predicate, so the IN list grows with the number of publicly visible sessions across every published event, and nothing in this file bounds it.

GetPublicSessionSpeakerFilterHandler

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Sessions.UseCases.GetPublicSessionSpeakerFilter · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Sessions/UseCases/GetPublicSessionSpeakerFilter/GetPublicSessionSpeakerFilterHandler.cs:15 · Level 11 · class (sealed)

• What it is: the handler for GetPublicSessionSpeakerFilterQuery. It resolves the visible session ids and returns a SessionSpeaker.SessionId IN (...) specification, so a join row is readable exactly when its parent session is (GetPublicSessionSpeakerFilterHandler.cs:15-17).
• Depends on: IUnitOfWork (:16); PublicConferenceVisibility; InlineSpecification<TEntity, TIdentifierType>; SessionSpeaker; Result; IQueryHandler<in TQuery, TResult> (:17).
• Concept introduced: the derived junction filter. The rule this handler enforces is not its own. It is one call to a shared resolver, PublicConferenceVisibility.GetVisibleSessionIdsAsync (:24-26), followed by a Contains over the returned ids. Nothing about "Accepted or unset status, inside a published event" appears in this file, which is the point: the definition lives once (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Application/Common/PublicConferenceVisibility.cs:57-82) and every read that must respect it derives from that one definition. [Rubric §11, Security] assesses whether a visibility rule holds on every surface that can reach the protected data. The summary and remarks on the resolver (PublicConferenceVisibility.cs:10-27) state the invariant: one definition of "publicly visible" backs the session, speaker, and junction read filters, so closing a leak in one place closes it everywhere, and everything is expressed as scalar id projections rather than navigation joins so the criteria stay translatable on any engine. [Rubric §1, SOLID]: this is the single-responsibility split in miniature. The resolver decides who is visible; the handler decides how that answer is shaped for one entity.
• Walkthrough
  1. Resolve (:24-26): GetVisibleSessionIdsAsync(unitOfWork, cancellationToken), which internally builds the cross-source session specification (PublicConferenceVisibility.cs:63-70) and projects the ids matching it through the spec-taking ListAsync overload (:75-79).
  2. Wrap and return (:28-30): ss => sessionIds.Contains(ss.SessionId) inside an InlineSpecification<TEntity, TIdentifierType>, returned as Result.Success. The handler has no failure branch and no conditional logic at all.
• Why it's built this way: the alternative, restating the status and published-event rules against navigation properties, would both duplicate the rule and produce criteria a non-relational provider could not translate. Two round trips (ids, then the filtered read) buy one rule and portable criteria.
• Where it's used: SessionSpeakersController's GetReadSpecificationAsync override (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.API/Controllers/Sessions/SessionSpeakersController.cs:73-83) is the only consumer, feeding the unpaged list (:85-88), paged list (:95-98), lookup (:114-117), and by-id (:122-125) reads, each [AllowAnonymous] (:86, :96, :115, :123) under the class-level permission requirement (:47). The doc comment on the override records what the hook buys (:66-71): every read action is scoped from one place, an excluded row is a 404 rather than a redacted record, and the actions below are attribute-only passthroughs.
• Testing: GetPublicSessionSpeakerFilterHandlerTests (MMCA.ADC/Tests/Modules/Conference/MMCA.ADC.Conference.Application.Tests/Sessions/UseCases/GetPublicSessionSpeakerFilter/GetPublicSessionSpeakerFilterHandlerTests.cs:18), four tests mirroring the category-item twin one for one: the success shape (:56), a row of a visible session matching (:65), a row of a hidden session excluded (:75), and no visible sessions matching nothing (:85).
• Caveats / not-in-source: identical to the category-item handler. A failed Result becomes null in the controller, meaning no filter (SessionSpeakersController.cs:82), and the materialized id list is unbounded in this file.

GetPublicSpeakerCategoryItemFilterQuery

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Speakers.UseCases.GetPublicSpeakerCategoryItemFilter · MMCA.ADC.Conference.Application/Speakers/UseCases/GetPublicSpeakerCategoryItemFilter/GetPublicSpeakerCategoryItemFilterQuery.cs:8 · Level 0 · record

• What it is: the parameterless query that asks for the read filter applied to the speaker-to-category-item junction. It carries no data at all; it exists purely as the typed key that resolves the matching handler out of DI.
• Depends on: nothing first-party. It is a bare public sealed record with no positional parameters and no members (GetPublicSpeakerCategoryItemFilterQuery.cs:8).
• Concept introduced: the filter query as a DI lookup token. Most CQRS messages in this module carry a payload. This one carries none, because the answer depends only on ambient data (which events are published, which sessions are on the BR-49 allow-list) and not on anything the caller can supply. Declaring it as a type anyway is what lets a controller inject IQueryHandler<GetPublicSpeakerCategoryItemFilterQuery, ...> and get the visibility rule through the same pipeline as every other read, rather than calling a static helper directly from the API layer. [Rubric §6, CQRS & Event-Driven] assesses whether reads are expressed as explicit, individually resolvable messages: even a zero-argument rule gets its own query type here. [Rubric §11, Security] assesses where authorization data is decided: the rule is derived server-side from published state, so there is no request field an anonymous caller could tamper with.
• Walkthrough: one line of code (:8). The XML doc above it (:3-7) is the load-bearing part: it records why the junction needs its own filter at all, namely that without it the join endpoints would list the categories of a hidden speaker (including the BR-66 locality assignments) and leak that speaker's existence even though the speaker row itself is filtered out.
• Why it's built this way: a record with no parameters still gets value equality and a compiler-generated ToString, and costs nothing to allocate per request. Keeping it distinct from GetPublicSpeakerFilterQuery means the two filters can diverge later (the junction read has no event context to scope by) without either handler growing a mode flag.
• Where it's used: constructed by SpeakerCategoryItemsController inside its GetReadSpecificationAsync override (MMCA.ADC.Conference.API/Controllers/Speakers/SpeakerCategoryItemsController.cs:79) and answered by GetPublicSpeakerCategoryItemFilterHandler.

GetPublicSpeakerFilterQuery

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Speakers.UseCases.GetPublicSpeakerFilter · MMCA.ADC.Conference.Application/Speakers/UseCases/GetPublicSpeakerFilter/GetPublicSpeakerFilterQuery.cs:20 · Level 0 · record

• What it is: the query that asks for the public-speaker read filter (BR-239), optionally narrowed to one event. It is a single-parameter record whose only field is a nullable event id that defaults to null.
• Depends on: the module alias EventIdentifierType (int for Conference, declared in MMCA.ADC.Conference.Shared/MMCA.ADC.Conference.GlobalUsings.IdentifierType.cs:8). No other first-party types.
• Concept introduced: the optional scope parameter. The same rule has to answer two different questions: "which speakers are public anywhere" and "which speakers are public on this event". Rather than two query types, one nullable parameter distinguishes them, and the default = null (GetPublicSpeakerFilterQuery.cs:20) means the un-scoped call site reads as new GetPublicSpeakerFilterQuery(). [Rubric §9, API & Contract Design] assesses contract expressiveness: the nullable is documented per-parameter (:15-19) as "the paged list has one, everything else passes none", so the two modes are part of the published contract rather than folklore. [Rubric §11, Security] as with the junction query: the id only narrows the rule, it can never widen it, because an unpublished or unknown scoped event resolves to an empty visible set (MMCA.ADC.Conference.Application/Common/PublicConferenceVisibility.cs:113-120).
• Walkthrough: public sealed record GetPublicSpeakerFilterQuery(EventIdentifierType? EventId = null) (:20). The <remarks> block (:9-14) explains the shape the handler will return: Speaker carries no status or event column of its own, so the rule cannot be expressed as a property comparison and is instead resolved into an id list and returned as a Speaker.Id IN (...) criteria, following the BR-132 precedent. That keeps the criteria free of navigation joins, so it stays translatable on any engine and Speaker keeps its by-id boundary to the Session and Event aggregates.
• Why it's built this way: making the scope optional rather than required is what lets one handler serve the paged list, the lookup, GetById, and the junction reads. The alternative (a required id plus a sentinel) would have pushed the "no context" case into every caller.
• Where it's used: constructed by SpeakersController in BuildPublicSpeakerSpecificationAsync (MMCA.ADC.Conference.API/Controllers/Speakers/SpeakersController.cs:92) and answered by GetPublicSpeakerFilterHandler.

ISessionFieldsRequest

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Sessions.Validation · MMCA.ADC.Conference.Application/Sessions/Validation/ISessionFieldsRequest.cs:13 · Level 0 · interface

• What it is: the read-only shape of the seven session fields that the create request and the update request validate identically. Both request records implement it, which is what lets one generic validator declare the shared rule list exactly once.
• Depends on: nothing. Seven get-only properties over BCL string and string?, no usings at all (ISessionFieldsRequest.cs:1).
• Concept introduced: the validation-shape interface. A request record is a transport DTO, not a domain type, so it has no natural base class to hang shared rules on, and the create and update requests are genuinely different records (create carries Id and implements ICreateRequest and ICacheInvalidating, MMCA.ADC.Conference.Application/Sessions/UseCases/Create/SessionCreateRequest.cs:11; update carries only EventId plus its own fields, .../Update/SessionUpdateRequest.cs:6). Extracting just the overlapping surface into an interface gives FluentValidation a generic constraint to work against: SessionFieldRules<T> is declared where T : ISessionFieldsRequest and can therefore write p => p.Title once for both records. [Rubric §1, SOLID] assesses interface segregation: this interface deliberately holds only the fields both operations validate the same way, nothing more. [Rubric §15, Best Practices & Code Quality] assesses whether adding a field is one edit or several: a new shared session field is added here, to the two records, and to one rule list, instead of to two independently maintained validators.
• Walkthrough: Title is non-nullable (:16) and is the only required member; Description (:19), Status (:22), LiveUrl (:25), RecordingUrl (:28), AccessibilityInfo (:31), and ResourceLinks (:34) are all string?. Every member is get-only, so implementing it costs an init-only property and nothing else, and no consumer can mutate a request through the interface.
• Why it's built this way: the <remarks> block (:8-12) records what is deliberately absent, which is the more interesting half. Fields validated by only one of the two operations stay off the interface on purpose: EventId is on both request records, but it is validated only on create, because BR-140 makes the owning event immutable and the update request carries it solely so UpdateSessionHandler can reject a change (MMCA.ADC.Conference.Application/Sessions/UseCases/Update/UpdateSessionHandler.cs:44-52). Likewise StartsAt, EndsAt, and RoomId are absent because their rule is not a field constraint at all: it is the cross-aggregate room and slot check in SessionRoomScheduling. The interface is the boundary between "same rule both ways" and "operation-specific", and keeping that boundary honest is what stops the shared rule list from growing When(...) clauses.
• Where it's used: implemented by SessionCreateRequest (SessionCreateRequest.cs:11) and SessionUpdateRequest (SessionUpdateRequest.cs:6), and used as the generic constraint on SessionFieldRules<T> (MMCA.ADC.Conference.Application/Sessions/Validation/SessionValidationRules.cs:113).

SessionEventIdRules<T>

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Sessions.Validation · MMCA.ADC.Conference.Application/Sessions/Validation/SessionValidationRules.cs:24 · Level 1 · class (sealed, generic)

• What it is: the reusable rule fragment asserting that a session request actually names a parent event. It is the only fragment in this file that validates a non-string field, and the only one that pins its own error code.
• Depends on: RequiredIdRules<T, TId> (its base class, SessionValidationRules.cs:25), System.Linq.Expressions.Expression<Func<T, EventIdentifierType>> for the property selector (:1,27), and the module alias EventIdentifierType.
• Concept introduced: the parameterized rule fragment, the shape every rule in this file follows. Rather than repeating RuleFor(x => x.EventId).NotEmpty() inside each command validator, the constraint lives once in a small generic AbstractValidator<T> subclass whose constructor takes the property selector; a concrete validator then folds it in with FluentValidation's Include(...). Because the fragment is generic in T, the same type validates the create request, the update request, or any future import request, each pointing the selector at its own property. The framework supplies the bases these fragments specialize: RequiredIdRules<T, TId> here, and RequiredStringRules<T> or OptionalStringRules<T> for the seven string fragments below. [Rubric §1, SOLID]: one fragment, one field contract, composed rather than copied. [Rubric §24, Forms/Validation/UX Safety] assesses whether input constraints are declared once and applied consistently at every entry path.
• Walkthrough: the expression-bodied constructor (:27-28) forwards base(selector, "an Event for the Session", "Session.EventId.Required"). The base (MMCA.Common/Source/Core/MMCA.Common.Application/Validation/CommonValidationRules.cs:142-148) chains a single NotEmpty() clause with the message You must specify {fieldName} and applies the optional error code (:145-147), which is why the field phrase carries its own article: the caller supplies "an Event for the Session" and the base interpolates it verbatim. Because EventIdentifierType is int (MMCA.ADC.Conference.Shared/MMCA.ADC.Conference.GlobalUsings.IdentifierType.cs:8), FluentValidation's NotEmpty tests against default(int), so the rule rejects a missing or zero event id; the base's remarks (CommonValidationRules.cs:133-139) note that the same check rejects Guid.Empty for a GUID key, which is what makes one base serve both id shapes.
• Why it's built this way: the stable error code is what the API error-mapping layer keys on, so it is part of the contract and not just display text. Keeping the event-id check as its own fragment (instead of folding it into the shared SessionFieldRules<T> list) is what lets the update path deliberately omit it: an update request also carries EventId, but re-parenting is rejected by the handler under BR-140 with the Session.EventId.Immutable error (MMCA.ADC.Conference.Application/Sessions/UseCases/Update/UpdateSessionHandler.cs:44-52), not by the validator.
• Testing: SessionValidationRulesTests (MMCA.ADC/Tests/Modules/Conference/MMCA.ADC.Conference.Application.Tests/Sessions/Validation/SessionValidationRulesTests.cs:8) pins both outcomes directly on the fragment: a supplied event id passes (:48) and default(int) fails (:55).
• Where it's used: Included by SessionCreateRequestValidator as its create-only delta (MMCA.ADC.Conference.Application/Sessions/UseCases/Create/SessionCreateRequestValidator.cs:16), directly beside the comment explaining the omission (:13-15). It is deliberately absent from SessionUpdateRequestValidator, whose whole body is one Include of the shared field rules (SessionUpdateRequestValidator.cs:12).

SessionAccessibilityInfoRules<T>

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Sessions.Validation · MMCA.ADC.Conference.Application/Sessions/Validation/SessionValidationRules.cs:86 · Level 7 · class (sealed, generic)

• What it is: the rule fragment bounding a session's optional accessibility-info text to 500 characters.
• Depends on: OptionalStringRules<T> (its base class, SessionValidationRules.cs:87) and SessionInvariants for the bound (:4,90).
• Concept reinforced: the parameterized rule fragment introduced by SessionEventIdRules<T>, in its shortest possible form. Deriving from the framework's OptionalStringRules<T> means the subclass declares nothing but a base(...) call: the base applies MaximumLength and no NotEmpty (MMCA.Common/Source/Core/MMCA.Common.Application/Validation/CommonValidationRules.cs:55-57), which is exactly the contract a nullable field needs. [Rubric §1, SOLID] and [Rubric §24, Forms/Validation/UX Safety].
• Walkthrough: sealed class SessionAccessibilityInfoRules<T> : OptionalStringRules<T> (:86-87); the constructor (:89) forwards base(selector, "Accessibility Info", SessionInvariants.AccessibilityInfoMaxLength) (:90). The label "Accessibility Info" is what appears in the generated length message; the bound is 500, reached through SessionInvariants (MMCA.ADC.Conference.Domain/Sessions/SessionInvariants.cs:25) which itself forwards to SessionDTO.AccessibilityInfoMaxLength (MMCA.ADC.Conference.Shared/Sessions/SessionDTO.cs:27).
• Why it's built this way: the number lives on the DTO, the lowest layer the UI can also reach, and the domain invariant re-exports it (SessionInvariants.cs:7-11). One constant therefore feeds the Blazor markup, this validator, the aggregate's own EnsureStringMaxLength guard (SessionInvariants.cs:80), and the EF column width, so a limit change cannot drift between layers.
• Where it's used: Included by SessionFieldRules<T> (SessionValidationRules.cs:122), which is the single list both the create and the update validator fold in.

SessionDescriptionRules<T>

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Sessions.Validation · MMCA.ADC.Conference.Application/Sessions/Validation/SessionValidationRules.cs:36 · Level 7 · class (sealed, generic)

• What it is: the rule fragment bounding a session's optional description to 4000 characters, the widest text bound in the session family.
• Depends on: OptionalStringRules<T> (:37) and SessionInvariants (:40).
• Concept reinforced: identical shape to SessionAccessibilityInfoRules<T>: nullable field, MaximumLength only, no NotEmpty.
• Walkthrough: the constructor (:39) forwards base(selector, "Session Description", SessionInvariants.DescriptionMaxLength) (:40); DescriptionMaxLength is 4000 (MMCA.ADC.Conference.Shared/Sessions/SessionDTO.cs:21, re-exported at MMCA.ADC.Conference.Domain/Sessions/SessionInvariants.cs:19), the same constant the aggregate's own optional-text guard cites (SessionInvariants.cs:76).
• Where it's used: Included by SessionFieldRules<T> (SessionValidationRules.cs:118).

SessionLiveUrlRules<T>

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Sessions.Validation · MMCA.ADC.Conference.Application/Sessions/Validation/SessionValidationRules.cs:61 · Level 7 · class (sealed, generic)

• What it is: the rule fragment bounding a session's optional live-stream URL to 2000 characters. Length only: it deliberately does not check that the value is a well-formed URL.
• Depends on: OptionalStringRules<T> (:62) and SessionInvariants (:65).
• Concept introduced: the deliberately weak format rule. Every other URL-ish field in a codebase invites a Uri.TryCreate check, and this one refuses it on purpose. The class doc (:55-60) records why: the value is stored as an opaque string for Sessionize compatibility, so whatever the import writes has to round-trip unchanged. Validating a format the upstream source does not guarantee would reject real data. The contrast is visible one file over in the framework: AbsoluteUrlRules<T> exists and adds an absolute http/https check on top of the same length bound (MMCA.Common/Source/Core/MMCA.Common.Application/Validation/CommonValidationRules.cs:85-94), so choosing OptionalStringRules<T> here is a decision, not an omission. [Rubric §24, Forms/Validation/UX Safety] assesses fitness of validation, not quantity: a rule that would fail on legitimate imported values is worse than no rule. [Rubric §26, Front-End Security] is the counterweight worth naming, and the framework doc states it plainly (CommonValidationRules.cs:77-83): a bounded string still accepts javascript: and data: values, so anything that renders this field as a link owns its own scheme checking.
• Walkthrough: the constructor (:64) forwards base(selector, "Live URL", SessionInvariants.LiveUrlMaxLength) (:65); LiveUrlMaxLength is 2000 (MMCA.ADC.Conference.Shared/Sessions/SessionDTO.cs:33, re-exported at MMCA.ADC.Conference.Domain/Sessions/SessionInvariants.cs:31). The aggregate's own guard is length-only too, with the same stated reason (SessionInvariants.cs:57,78).
• Caveats / not-in-source: the fragment guarantees length only. Whether any specific consumer sanitizes the value before rendering is not determinable from this file.
• Where it's used: Included by SessionFieldRules<T> (SessionValidationRules.cs:120).

SessionRecordingUrlRules<T>

MMCA.ADC.Conference.Application · MMCA.ADC.Conference.Application.Sessions.Validation · MMCA.ADC.Conference.Application/Sessions/Validation/SessionValidationRules.cs:74 · Level 7 · class (sealed, generic)

• What it is: the rule fragment bounding a session's optional recording URL to 2000 characters, length only.
• Depends on: OptionalStringRules<T> (:75) and SessionInvariants (:78).
• Concept reinforced: the same deliberately weak format rule as SessionLiveUrlRules<T>, with the identical rationale recorded in its own doc block (:68-73): the value is an opaque Sessionize-compatible string.
• Walkthrough: the constructor (:77) forwards base(selector, "Recording URL", SessionInvariants.RecordingUrlMaxLength) (:78); RecordingUrlMaxLength is 2000 (MMCA.ADC.Conference.Shared/Sessions/SessionDTO.cs:36, re-exported at MMCA.ADC.Conference.Domain/Sessions/SessionInvariants.cs:34).
• Where it's used: Included by SessionFieldRules<T> (SessionValidationRules.cs:121).