Move Infrastructure.FileUpload into Features.PhotoUpload (#290)

This commit is contained in:
Aaron Po
2026-09-12 00:22:19 -04:00
committed by GitHub
parent ce2c90070e
commit 180ed41e68
18 changed files with 27 additions and 47 deletions

View File

@@ -91,7 +91,6 @@ flowchart TB
I1["Database.Connection"]
I3["Infrastructure.PasswordHashing"]
I4["Email.Templates"]
I5["Infrastructure.FileUpload"]
end
DB[("Database (SQL Server)")]
@@ -166,8 +165,7 @@ brewery photo upload command) rather than bound to an HTTP route directly.
- `Domain.Entities`, `Domain.Exceptions`
- `Database.Connection` (generic ADO.NET connection/command plumbing) plus
whichever infrastructure project the slice needs (`Infrastructure.PasswordHashing`
for Users, `Infrastructure.Email.Templates` for
Emails, `Infrastructure.FileUpload` for PhotoUpload)
for Users, `Infrastructure.Email.Templates` for Emails)
- `Shared.Contracts`, `Shared.Application`
- No other `Features.*` project, with two exceptions: `Features.Users`
references `Features.PhotoUpload` directly for avatar uploads, and
@@ -209,7 +207,6 @@ whichever slices need them
| `Database.Connection` | Generic ADO.NET connection/command plumbing (`DefaultSqlConnectionFactory`, the abstract `DapperRepository` base class), not domain-specific; each slice's own `Repository/` folder builds on this. |
| `Infrastructure.PasswordHashing` | Argon2id password hashing. |
| `Infrastructure.Email.Templates` | Email template rendering (Razor components). |
| `Infrastructure.FileUpload` | `IFileStorageProvider` abstraction over S3-compatible object storage, implemented by `S3FileStorageProvider` (targets the SeaweedFS container in dev; any S3-compatible endpoint in other environments) using the AWS SDK's `AmazonS3Client` with `ForcePathStyle = true`. |
**Dependencies**:

View File

@@ -99,7 +99,7 @@ see the notes for what else each of those foundation projects pulls in.
- `Domain.Exceptions` (referenced by nearly every project directly, including
all of `Shared.Contracts` and each feature slice)
- `Infrastructure.Configuration` (the shared options-binding project
referenced by `Database.Connection`, `Infrastructure.FileUpload`,
referenced by `Database.Connection`, `Features.PhotoUpload`,
and `Features.Emails` directly)
- both are plumbing-level dependencies of nearly everything above, and drawing
them would just add a second copy of the same fan-in

View File

@@ -24,7 +24,6 @@ end
subgraph INFRA["Slice-specific Infrastructure"]
direction LR
PwdHash["Infrastructure.PasswordHashing"]
FileUpload["Infrastructure.FileUpload"]
EmailTemplates["Infrastructure.Email.Templates"]
end
@@ -33,7 +32,7 @@ EmailsSlice == project ref, handles UserRegisteredNotification & ConfirmationEma
BrewerySlice --> FOUNDATION
LocationsSlice --> FOUNDATION
BeersSlice --> FOUNDATION
PhotoSlice --> FOUNDATION & FileUpload
PhotoSlice --> FOUNDATION
UsersSlice --> FOUNDATION & PwdHash
EmailsSlice --> EmailTemplates
DBConn -- Dapper SQL, no ORM --> Tables[("SQL Server<br>Tables")]

View File

@@ -255,8 +255,8 @@ SMTP_FROM_NAME=The Biergarten App # Optional, defaults to "The Biergarten
### File storage configuration (backend)
Read by `Infrastructure.FileUpload/S3FileStorageProvider.cs` for uploading and
retrieving photos via an S3-compatible object store.
Read by `Features.PhotoUpload/Services/S3FileStorageProvider.cs` for uploading
and retrieving photos via an S3-compatible object store.
```bash
SEAWEEDFS_SERVICE_URL=http://seaweedfs:8333 # Required, no default