Lesson 119: Orchestrating the Auction Transaction Lifecycle
Objective
Build a central Transaction Lifecycle Manager that coordinates the various managers responsible for an auction after it closes.
Why This Lesson?
Currently, several managers know about parts of the workflow:
Auction Manager
Payment Manager
Transaction Manager
Transfer Manager
External Provider Manager
Activity Log
Notification Manager
Each performs its own task.
However, there is no single class responsible for the overall business process.
This means workflow logic is currently scattered across multiple classes.
Current Flow
Auction Ends
│
▼
Winner Determined
│
▼
Transaction Created
│
▼
Payment Submitted
│
▼
Payment Verified
│
▼
Ownership Transfer
│
▼
Transaction Completed
Every step currently triggers another manually.
Proposed Architecture
Introduce a new class:
Flipnzee_Transaction_Lifecycle_Manager
Its responsibility is orchestration—not storage.
Think of it as the project manager of the plugin.
Responsibilities
The Lifecycle Manager will coordinate:
Auction Closed
│
▼
Create Transaction
│
▼
Notify Winner
│
▼
Wait For Payment
│
▼
Verify Payment
│
▼
Create Transfer Record
│
▼
Notify Seller
│
▼
Ownership Transfer
│
▼
Complete Transaction
│
▼
Notify Buyer
Notice that it doesn’t replace the other managers.
It simply tells them when to perform their work.
New Responsibilities
The Lifecycle Manager may call methods such as:
Transaction_Manager::create()
Payment_Manager::create()
Transfer_Manager::create_transfer()
Notification_Manager::send()
Activity_Log::log()
External_Provider_Manager::create_provider()
Each manager remains focused on its own domain.
Benefits
Instead of this:
Auction Manager
│
├── calls Payment
├── calls Transfer
├── calls Activity Log
├── calls Notifications
we move to:
Auction Manager
│
▼
Lifecycle Manager
│
├── Transaction
├── Payment
├── Transfer
├── Activity Log
├── Notifications
└── External Provider
This greatly reduces coupling.
Design Principle
This lesson introduces an important software engineering principle:
Managers should perform work. Coordinators should orchestrate work.
The Lifecycle Manager is a coordinator.
The other managers remain specialists.
Future Expansion
Once this class exists, adding features becomes much easier.
For example:
Escrow.com
↓
Lifecycle Manager
↓
Transfer Manager
or
Stripe Webhook
↓
Lifecycle Manager
↓
Payment Verified
↓
Transfer Manager
No existing managers need major changes.
What We’ll Build
During Lesson 119 we’ll implement:
Flipnzee_Transaction_Lifecycle_Manager- Lifecycle orchestration methods
- Central workflow entry points
- Manager-to-manager coordination
- Cleaner separation of responsibilities
- Improved maintainability for future integrations
Learning Objectives
By the end of Lesson 119, readers will understand:
- The difference between coordination and business logic
- Why orchestration classes are useful in large plugins
- How to reduce coupling between components
- How to design a scalable workflow architecture for complex WordPress plugins