Table of the Pottmayer.Tars projects with their architectural level, usage classification and role.
See taxonomy.md for the complete definition of the levels and classifications.
| Project |
Level |
Classification |
Role |
Pottmayer.Tars.Core.Primitives |
Abstractions |
Essential |
Result, Error, Optional<T>, utility extensions |
Pottmayer.Tars.Core.Mediator.Abstractions |
Abstractions |
Optional |
mediator, request, notification and pipeline contracts |
Pottmayer.Tars.Core.Mediator |
Runtime |
Optional |
mediator implementation and per-assembly DI scanners |
Pottmayer.Tars.Core.Cqrs |
Runtime |
Architectural style |
bases for commands/queries and the exception-mapping behavior |
Pottmayer.Tars.Core.Ddd |
Abstractions |
Architectural style |
Entity, AggregateRoot, domain events, dispatcher |
Pottmayer.Tars.Core.Localization.Abstractions |
Abstractions |
Optional |
IMessageProvider, IMessageSource |
Pottmayer.Tars.Core.Localization |
Runtime |
Optional |
message source composition, InMemoryMessageSource, ResourceManagerMessageSource |
Pottmayer.Tars.Core.Localization.AspNetCore |
Host Integration |
Optional |
RequestLocalizationMiddleware, IStringLocalizer, culture options |
| Project |
Level |
Classification |
Role |
Pottmayer.Tars.Caching.Abstractions |
Abstractions |
Optional |
contracts (ICacheStore, ICacheSerializer, ICacheKeyBuilder) |
Pottmayer.Tars.Caching |
Runtime |
Optional |
default JSON serializer, default key builder, abstract CachingOptions base |
Pottmayer.Tars.Caching.Memory |
Provider |
Optional |
provider over IMemoryCache, MemoryCachingOptions |
Pottmayer.Tars.Caching.Redis |
Provider |
Optional |
Redis provider, RedisCachingOptions (connection + shared settings) |
| Project |
Level |
Classification |
Role |
Pottmayer.Tars.Messaging.Abstractions |
Abstractions |
Optional |
integration messaging contracts: IIntegrationEvent, IIntegrationEventBus, IIntegrationEventHandler<T>, IntegrationEventNameAttribute |
Pottmayer.Tars.Messaging |
Runtime |
Optional |
InProcessIntegrationEventBus, handler scanning, DI registration |
Pottmayer.Tars.Messaging.EntityFrameworkCore |
Provider |
Optional |
transactional in-process outbox: OutboxIntegrationEventBus, outbox table, per-database relay BackgroundService, at-least-once delivery — no broker required |
Pottmayer.Tars.Messaging.Broker |
Runtime |
Optional |
shared broker runtime: name-to-type registry, portable route and subscription model, BrokerCapabilities, last-mile dispatcher |
Pottmayer.Tars.Messaging.MassTransit |
Provider |
Optional |
MassTransit-backed bus, relay consumer, logical entity name formatter, TarsMassTransitOptions; and the transport-agnostic composite orchestrator (AddTarsMassTransitComposite + IMassTransitTransport) that runs several transports in one process — each transport contributed by its own provider package, so an app references only the transports it uses (multi-transport.md) |
Pottmayer.Tars.Messaging.MassTransit.RabbitMq |
Provider |
Optional |
RabbitMQ transport: exchange topology, queue bindings, routing key application, TarsRabbitMqOptions, DI helpers |
Pottmayer.Tars.Messaging.MassTransit.Kafka |
Provider |
Optional |
Kafka transport over the MassTransit rider: producer and topic endpoint per event type, TarsKafkaOptions, DI helpers |
Pottmayer.Tars.Messaging.MassTransit.EntityFrameworkCore |
Provider |
Optional |
transactional outbox over MassTransit's own EF Core outbox, for every broker |
| Project |
Level |
Classification |
Role |
Pottmayer.Tars.Communication.Email.Abstractions |
Abstractions |
Optional |
e-mail contracts: IEmailSender, EmailMessage, EmailDeliveryResult |
Pottmayer.Tars.Communication.Email |
Runtime |
Optional |
LoggingEmailSender (fake) and DI registration |
Pottmayer.Tars.Communication.Email.MailKit |
Provider |
Optional |
SMTP provider over MailKit, MailKitEmailOptions, DI helpers |
Pottmayer.Tars.Communication.Telegram.Abstractions |
Abstractions |
Optional |
Telegram Bot API contracts: ITelegramClient, message/update/inline-keyboard models, TelegramException, escaping and webhook helpers |
Pottmayer.Tars.Communication.Telegram |
Provider |
Optional |
Bot API implementation over HttpClient: sending, long polling, file download, webhook management, TelegramOptions, DI helpers |
| Project |
Level |
Classification |
Role |
Pottmayer.Tars.Ai.Abstractions |
Abstractions |
Optional |
shared across AI capabilities: AiException (permanent/transient) |
Pottmayer.Tars.Ai.Chat.Abstractions |
Abstractions |
Optional |
chat-completion contracts: IAiChatCompletionClient, IAiChatCompletionClientFactory, ChatRequest/ChatCompletion/ChatMessage/ToolDefinition/ToolCall/TokenUsage |
Pottmayer.Tars.Ai.Chat |
Runtime |
Optional |
keyed-DI provider factory (AddTarsAiClientFactory) |
Pottmayer.Tars.Ai.Chat.Gemini |
Provider |
Optional |
Gemini provider over generateContent, per-request API key, GeminiAiOptions, DI helpers |
| Project |
Level |
Classification |
Role |
Pottmayer.Tars.Data.Abstractions |
Abstractions |
Essential (data axis) |
provider-agnostic contracts: IUnitOfWork, IUnitOfWorkFactory, IDataContext, IDataContextAccessor, IDataContextFactory, IKeyedDataContextFactory, IStandardRepository, IRepository, IRepositoryResolver, IMultiDatabaseCoordinator, QueryParams, FilterSpec, FilterOperator, SortOption, DataQueryResult, DataKeys |
Pottmayer.Tars.Data |
Runtime |
Essential (data axis) |
provider-agnostic runtime: DataContextAccessor, composite/keyed IDataContextFactory, UnitOfWorkFactory, RepositoryResolver, MultiDatabaseCoordinator, QueryParams translation, shared DI (AddTarsDataContextAccessor, AddTarsDataContextFactory, AddTarsUnitOfWorkFactory, AddTarsMultiDatabaseCoordination, AddTarsDataRepositoriesFromAssemblies) |
| Project |
Level |
Classification |
Role |
Pottmayer.Tars.Data.Relational.Abstractions |
Abstractions |
Optional |
relational contracts: IRelationalRepository (adds Queryable()), IDataConnectionResolver, IDataConnectionDescriptor, DbProvider, ITenantConnectionStringProvider, ITenantSchemaProvider |
Pottmayer.Tars.Data.Relational |
Runtime |
Optional |
EF Core + Dapper implementation, RelationalDbContext, DataContext, StandardRepository, connection resolution, AddTarsRelationalData |
| Project |
Level |
Classification |
Role |
Pottmayer.Tars.Data.Document.Abstractions |
Abstractions |
Optional |
document contracts: IMongoConnectionResolver, IMongoConnectionDescriptor, MongoConnectionResolutionContext |
Pottmayer.Tars.Data.Document.MongoDB |
Runtime |
Optional |
MongoDB implementation: session/transaction MongoDataContext, MongoStandardRepository, connection resolution, AddTarsMongoData |
The relational and document axes share the same provider-agnostic contracts and runtime, so an application
can register any mix of relational and MongoDB keys. See MongoDB provider.
Kept only as migration history. New projects should use Data.Abstractions + Data.Relational.Abstractions + Data.Relational.
| Project |
Status |
Replacement |
Pottmayer.Tars.Data.Core |
Obsolete |
merged into Data.Relational |
Pottmayer.Tars.Data.EFCore |
Obsolete |
merged into Data.Relational |
Pottmayer.Tars.Data.Dapper |
Obsolete |
merged into Data.Relational |
Pottmayer.Tars.Data.Hybrid |
Obsolete |
default behavior of Data.Relational |
| Project |
Level |
Classification |
Role |
Pottmayer.Tars.Multitenancy.Abstractions |
Abstractions |
Optional |
tenant context, resolver, pipeline, catalog, store and execution contracts |
Pottmayer.Tars.Multitenancy |
Runtime |
Optional |
resolution pipeline, agnostic resolvers, in-memory catalog, store, per-tenant execution |
Pottmayer.Tars.Multitenancy.AspNetCore |
Host Integration |
Optional |
middleware and HTTP resolvers (header, subdomain) |
| Project |
Level |
Classification |
Role |
Pottmayer.Tars.Observability.Abstractions |
Abstractions |
Optional |
shared vocabulary: TarsTelemetry (source/meter naming), TarsCorrelation (header/property names) |
Pottmayer.Tars.Observability |
Runtime |
Optional |
options + granular DI for the OpenTelemetry pipeline (traces, metrics, logs) and native ILogger logging over OTLP |
Pottmayer.Tars.Observability.Serilog |
Provider |
Optional |
opt-in Serilog logging provider: console + OTLP sink, alternative to native logging |
Pottmayer.Tars.Observability.AspNetCore |
Host Integration |
Optional |
ASP.NET Core / HttpClient instrumentation and the correlation-id middleware |
| Project |
Level |
Classification |
Role |
Pottmayer.Tars.Web.Http.Abstractions |
Abstractions |
Optional |
HTTP contracts, envelopes, wrap decision, pagination |
Pottmayer.Tars.Web.Http |
Runtime |
Optional |
HttpResponse, HttpErrorResponse, DefaultHttpErrorMapper, WrapDecisionService |
Pottmayer.Tars.Web.Http.AspNetCore |
Host Integration |
Optional |
MVC/Minimal API filters, exception filter, HTTP extensions, options |
| Project |
Level |
Classification |
Role |
Pottmayer.Tars.Security.Identity.Abstractions |
Abstractions |
Optional |
DTOs, authentication contracts, stores, token services, transport contracts |
Pottmayer.Tars.Security.Identity |
Runtime |
Optional |
JWT issuance/validation, refresh, revocation, magic link, core policies |
Pottmayer.Tars.Security.Identity.AspNetCore |
Host Integration |
Optional |
endpoints, HTTP transport, JWT bearer, API key, OAuth |
| Project |
Level |
Classification |
Role |
Pottmayer.Tars.UserContext.Abstractions |
Abstractions |
Optional |
user context contracts |
Pottmayer.Tars.UserContext |
Runtime |
Optional |
UserContext, AsyncLocalUserContextAccessor, agnostic resolution |
Pottmayer.Tars.UserContext.AspNetCore |
Host Integration |
Optional |
middleware and bridge with HttpContext |
- The framework publishes multiple small packages instead of a single monolith.
Data.Abstractions (contracts) and Data (shared runtime) are the base of the entire data family — every axis depends on them.
Web.Http replaces the old Presentation.Rest family.
- When using the relational axis, reference
Data.Relational.Abstractions + Data.Relational; for the document axis, Data.Document.Abstractions + Data.Document.MongoDB. Both pull in Data.Abstractions + Data automatically, and both can be referenced together in one application.
- When a
*.AspNetCore package exists, it is the correct place for middleware, endpoints, filters and integration with the specific host.