Object lifecycle management, state machine

[VladymyrPylypchatin]

Since we have an object-oriented system design, objects are the system's foundation.

It would be handy to be able to standartaise how we define object lifecycle and manage it.

Everything is an object.

Every object have live.

How we can standardise definition of object lives

Love the explanation here: https://docs.stripe.com/payments-api/tour

> Everything is an object

Everything in your Stripe account is an object, whether you create it with the API or not. Your balance corresponds to a Balance object, you track customers with Customer objects, you store payment details in PaymentMethod objects, and so on.

Even low-code and no-code integrations produce these objects. So do actions you perform in the Dashboard. For instance, when you manually create a customer in the Dashboard, it still creates a Customer object.

> Objects have lives Stripe integrations handle complicated processes.

The API uses a single object to track each process. You create the object at the start of the process, and after every step you can check its status to see what needs to happen next. This is sometimes referred to as a state machine.

For instance, while completing a payment, a customer might try several payment methods. If one payment method fails, a status of requires_payment_method lets you know to prompt the customer for another.

> An integration is made out of cooperating objects To accept a payment, a system needs to create several core objects and manage them through several states.

Your Stripe integration is a system that handles this creation and management by communicating with Stripe.

Some integrations do a lot more than that: track customers, manage subscriptions, etc. But their core payment functionality still comes from the same objects and steps, with more objects added around that core.

[VladymyrPylypchatin]

Yes, an object typically has only one state at a given point in time in a state machine or lifecycle model. This is a core principle of state machines, which ensure that an object is in a clearly defined state at any moment. The object can only transition between states based on specific events or conditions, and it cannot be in multiple states simultaneously.

Key Points: Single State Principle: An object can be in only one state at a time. For example, a payment object cannot be both in a "Processing" state and a "Succeeded" state at the same time.

State Transitions: The object moves from one state to another based on triggers, actions, or events. For example, a Payment Intent in Stripe might transition from requires_payment_method to requires_confirmation once a payment method is provided.

Sequential Progression: The object progresses through its lifecycle in a well-defined sequence of states. Once it moves to a new state, the previous state is no longer active.

[VladymyrPylypchatin]

The key part here is after every step you can check its status to see what needs to happen next

Object lifecycle statuses should inform what Action should you take next.

[VladymyrPylypchatin]

Also I think another important part there is difference between Stage and State/status.

State/status is what an object is.

Stage is what activity is happens within the process.

E.g. Status: Payment Intent IS Confirmed Stage: Processing -> system does processing of the payment intent