Reflections on Transaction System Design: Principles, Paradigms, and Patterns

The author recounts the experience of rebuilding a large‑scale transaction system after its first major refactor, emphasizing the need for clear design goals, measurable objectives, and a systematic approach to architecture that avoids the mystique of the word "architecture".

He introduces the concept of "soft ware"—software that is flexible by nature—and describes how the original system, written in Python eight years ago, evolved through stages of Java and Go adoption, each bringing its own trade‑offs in expressiveness, safety, and developer productivity.

Key design decisions are framed as a loop: purpose → goals → core design → design principles → detailed sub‑system design. The author stresses that software should be as adaptable as hardware, with changes costing minimal effort.

Programming paradigms are examined, advocating a mixed approach that starts with object‑oriented programming (OOP) for high‑level structure while allowing functional programming (FP) for specific, performance‑critical components such as order amount calculations.

Fundamental design principles are highlighted, especially the SOLID principles. For example, the Single Responsibility Principle (SRP) is illustrated by splitting delivery evaluation logic into distinct domain concepts, and the Dependency Inversion Principle (DIP) is demonstrated with a simplified state‑transition example:

public class Order {
    // States
    public static final int ACCEPT = 5;
    public static final int SETTLED = 9;
    // Events
    public static final int ARRIVED = 1; // 订单送达
    public void event(int event) {
        switch (state) {
            case ACCEPT:
                switch (event) {
                    case ARRIVED:
                        state = SETTLED;
                        // to do action
                        break;
                }
        }
    }
}

A more maintainable alternative using a transition table is also presented:

# 完结订单
add_transition(trigger=ARRIVED,
               src=ACCEPT,
               dest=SETTLED,
               on_start=_set_order_settled_at,
               set_state=_set_state_with_record, // 变更状态
               on_end=_push_to_transcore)

def event_fire(event, current_state):
    for transition in transitions:
        if transition.on_start == current_state and transition.trigger == event:
            transition.on_start()
            current_state = transition.dest
            transition.on_end()

The article then moves to domain‑driven design (DDD), explaining bounded contexts, a ubiquitous language, and how separating concerns into Extension, Domain, Business, and Infra packages improves modularity and testability.

Layered architecture is discussed, referencing Martin Fowler’s classic layering and contrasting it with a CQRS approach, illustrating how proper layering keeps domain logic independent of infrastructure details.

Finally, the author acknowledges that no single "silver bullet" exists for building flexible systems; continuous reflection, disciplined use of principles, and pragmatic trade‑offs are essential for sustainable backend evolution.