Design patterns on IBM i are less about fashionable labels and more about building code that your team can maintain, test, and extend without fear.
Why this matters
Teams inherit long-lived systems. Clear boundaries and consistent patterns help the next developer understand the code without reverse engineering everything from scratch.
Core concepts
Separation of concerns
Keep business rules, file access, and user interaction from collapsing into one large routine.
Modular services
Break reusable logic into procedures or service programs so it can be shared cleanly.
Stable interfaces
Design entry points that make it easier to change the internals later.
Testability
The easier a unit is to test, the easier it is to trust during change.
Practical example
A pricing routine can live in one module, the database access in another, and the display logic in a third so each part can change without rewriting the whole program.
Common mistakes
- Letting every change create a new one-off structure.
- Mixing business logic and I/O so tightly that both become hard to test.
- Optimizing for speed of coding today at the cost of maintainability tomorrow.
Where this fits in the series
If you want the platform foundation first, read the pillar article, What Is AS400 (IBM i)? A Complete Beginner’s Guide.