63 lines
1.5 KiB
Markdown
63 lines
1.5 KiB
Markdown
# Mail Order Bot Migration Plan
|
|
|
|
## Goal
|
|
|
|
Migrate `mail_order_bot` to the new PLBA model:
|
|
- application assembled by `ApplicationModule`
|
|
- runtime execution owned by `Worker`
|
|
- business behavior implemented in routines/services
|
|
|
|
## Target structure
|
|
|
|
### Application module
|
|
|
|
`MailOrderBotModule` should:
|
|
- build domain services
|
|
- build routines
|
|
- register workers
|
|
- register optional health contributors
|
|
|
|
### Workers
|
|
|
|
Initial workers:
|
|
- `MailPollingWorker`
|
|
- `EmailProcessingWorker`
|
|
- optional `ReconciliationWorker`
|
|
|
|
Each worker should own only runtime behavior:
|
|
- start/stop
|
|
- execution loop
|
|
- thread model
|
|
- health/status
|
|
|
|
### Routines
|
|
|
|
Initial routines:
|
|
- `MailPollingRoutine`
|
|
- `EmailProcessingRoutine`
|
|
- `ReconciliationRoutine`
|
|
|
|
Each routine should own business behavior:
|
|
- fetch messages
|
|
- parse message payload
|
|
- call domain services
|
|
- persist changes
|
|
- report business failures upward
|
|
|
|
## Migration steps
|
|
|
|
1. Extract business logic from current worker-like components into routines/services.
|
|
2. Implement thin workers that call those routines.
|
|
3. Register workers from `MailOrderBotModule`.
|
|
4. Use runtime health and status only through worker state.
|
|
5. Keep any local queue only as an implementation detail if it still helps.
|
|
|
|
## Optional queue usage
|
|
|
|
If email processing still benefits from buffering, `InMemoryTaskQueue` may be used inside the application.
|
|
|
|
Important:
|
|
- it should remain an app-level detail
|
|
- it should not define the platform contract
|
|
- the main architecture should still be described through workers and routines
|