When to Build Extensibility Early? Three Scenarios That Justify It

Extensibility design should be based on whether you truly understand the business domain, not on your ability to predict the future.

I start with my experience in the chain‑store industry, where integrating a large number of external systems is mandatory.

Determinism in the chain‑store sector

During my time in that sector I repeatedly had to connect to systems such as Kingdee, Juepei Logistics, Wangdian Tong, various invoicing platforms, logistics delivery platforms, Express Logistics 100, Heshi, Beisen, DingTalk, store inspection systems, etc. New integrations keep arriving.

Because the need for a unified external‑system gateway is certain, I design it at the beginning of each project. Adding a new system only requires a new strategy implementation class and a configuration entry; existing code remains untouched.

This is not over‑design or a love of design patterns; it reflects the business model that external‑system integration is inevitable.

Other sectors share the same certainty

Payment systems illustrate the same point: the first release may only support WeChat Pay, but additional channels such as Alipay are added later. The multi‑channel model is a proven industry fact, not a future guess.

Marketing activities in e‑commerce are also inherently multi‑type (full‑reduction, discount, gifts, flash sale, group buying, pre‑sale). No system implements only one type; extensibility must be considered from day one.

Payment, marketing, and external‑system integration all share the characteristic of being naturally multi‑implementation domains, so early extensibility points are justified.

How to judge whether a domain has this determinism

Industry patterns

Some domains are intrinsically extensible—payment channels, marketing activities, notification mechanisms, approval flows, risk‑control rules—because countless projects have shown they require multiple implementations.

Product planning

Sometimes the product roadmap already specifies upcoming integrations (e.g., Alipay next month, Apple Pay in two months, overseas payment in three). In such cases early abstraction is reasonable because the need is confirmed.

Historical changes

If a piece of code has been modified repeatedly (e.g., a marketing rule that grew from one if statement to dozens), continuing to add conditional branches becomes untenable, and patterns like Strategy or Chain of Responsibility naturally emerge.

Source of determinism: Industry patterns – Typical scenario: payment channels, marketing activities, notification systems – Judgment: other systems in the domain already have multiple implementations – Worth early design: Yes

Source of determinism: Product planning – Typical scenario: upcoming channels or features on the roadmap – Judgment: roadmap clearly schedules the integration – Worth early design: Yes

Source of determinism: Historical changes – Typical scenario: code that has been altered many times for similar requirements – Judgment: same‑type demand has already caused multiple modifications – Worth early design: Yes

This table can serve as a decision tool: when faced with a design decision, ask which of the three sources applies. If none apply, the extensibility design may be based on speculation.

Extensibility built on speculation

Object‑oriented design principles often assume that writing interfaces and abstractions means we know how the system will evolve. Most of the time we do not.

Extending payment processing early is justified because the industry proves it will expand. If a developer merely imagines future needs like overseas support, AI integration, or multi‑tenant capability, that is not backed by evidence.

A good abstraction must be explainable; if you cannot justify it, it should not remain in the code.

Conclusion

The basis for extensibility design is not the possibility of future change but solid business knowledge that confirms the change will happen. When you understand an industry well, you are not designing for a hypothetical future but faithfully modeling the domain’s inherent variability.

Design patterns solve code‑level problems, but domain knowledge decides where patterns should be applied. The latter matters far more.