When you’re building something big, it’s easy to fall into the “just toss it into Common” trap.
You know the one — a giant “Shared” library where every random helper, DTO, and extension method ends up living rent-free.
That’s fine until you wake up one day and realize you’ve created a god-class library that nobody understands and everybody hates.
I didn’t want that. HoneyDrunk (my indie dev playground) is meant to scale cleanly, so I sat down and mapped out what the shared package ecosystem should actually look like.
This post is me brain-dumping how I’m structuring it, so future-me doesn’t scream at past-me later.
Core First, Junk Drawer Never
The heart of the platform starts with fundamentals:
-
HoneyDrunk.Core→ base entities, domain events, common exceptions -
HoneyDrunk.Validation→ validators and rule sets -
HoneyDrunk.Security→ Argon2 hashing, JWT utilities, auth helpers -
HoneyDrunk.Caching→ Redis + memory abstractions -
HoneyDrunk.Configuration→ Key Vault + strongly typed configs -
HoneyDrunk.FeatureFlags→ clean feature toggles
These are primitives, not business logic. They’re the Lego bricks everything else is built on.
Data + Networking
-
HoneyDrunk.Data→ EF Core patterns, DbContext helpers, migrations -
HoneyDrunk.Storage→ blob/S3/local filesystem abstraction -
HoneyDrunk.Http→ resilient HttpClient factory (retry, jitter, circuit breaker) -
HoneyDrunk.RestService→ less boilerplate overHttp -
HoneyDrunk.Grpc→ shared contracts + helpers -
HoneyDrunk.SignalR→ hub contracts + client utilities
Messaging vs Notifications
Here’s where people mess it up. Messaging ≠ Notifications.
-
HoneyDrunk.Messaging→ system-to-system (pub/sub, service bus commands) -
HoneyDrunk.Notifications.Email→ user-facing email -
HoneyDrunk.Notifications.Sms→ text messages -
HoneyDrunk.Notifications.Push→ mobile + web push
👉 One is about services talking to each other. The other is about talking to humans. Don’t cross the streams.
Observability + Quality
If you’re not measuring, you’re guessing.
-
HoneyDrunk.Observability→ Serilog, OpenTelemetry, metrics, tracing -
HoneyDrunk.Testing→ Moq setups, Cypress helpers, fixtures, test utilities
Commerce (Not Just Payments)
I almost made a HoneyDrunk.Payments package. Glad I stopped. Payments are just one part of a bigger story.
Instead:
-
HoneyDrunk.Commerce.Orders -
HoneyDrunk.Commerce.Payments -
HoneyDrunk.Commerce.Billing
That way I can handle orders, invoices, and subscriptions without bending a “Payments” package into something it was never meant to be. Abstraction matters.
Integrations
These are where the fun APIs live:
-
HoneyDrunk.Integrations.Streaming→ Twitch, YouTube, Kick -
HoneyDrunk.Integrations.Media→ AniList, TMDB -
HoneyDrunk.Integrations.GamingPlatforms→ Steam, Epic, Xbox APIs -
HoneyDrunk.Integrations.Social→ Discord, Twitter/X, Reddit
Tooling + SDKs
Ops and client devs need love too:
-
HoneyDrunk.Tooling.DevOps→ DACPAC utilities, pipeline helpers, infra scripts -
HoneyDrunk.Sdk.DotNet→ SDK for .NET consumers -
HoneyDrunk.Sdk.JavaScript(future) → Next.js + Expo SDKs
Satellite Sites (The Consumers)
All these packages? They’re not the product. They’re the engine room.
The actual user-facing pieces are the satellites:
- Next.js → public front door
- Expo mobile app → push notifications + community nudges
- Blazor admin → manage users, payments, bugs
- Astro marketing site → blog, docs, branding hub
🚫 Rule #1: satellites don’t talk to databases. They hit APIs/SDKs only.
Wrapping It Up
Every package name is a bet on the future.
Go too narrow and you box yourself in. Go too vague and you build a junk drawer.
HoneyDrunk is my shot at doing it the right way: explicit names, clear boundaries, and room to grow without rewriting half the platform.
Abstractions aren’t academic — they’re strategy.
And if I screw it up, future-me will definitely roast past-me for it.
Originally published at: https://www.tatteddev.com/blog/abstractions-packages-and-satellite-sites/
Top comments (0)