The complexity of an ERP is not in how hard any single feature is. It is in how many times the same fact gets restated, multiplied by how many tables, multiplied again by how many customizations.
A thirty-post series written for iThome Ironman 2026, a thirty-day technical writing challenge in Taiwan, published from 2026-08-17 to 2026-09-15. The series is complete.
This series is not about building one form with a framework. It is about designing a framework that can drive hundreds of forms: the single source of truth lives in definitions rather than code, and the database structure, SQL, screens for multiple front ends, validation and computation, multiple languages, multi-tenancy and customization are all derived from the same layer of definitions. The Northwind case study verifies it, but the case study is evidence, not the subject.
It is about mechanisms and trade-offs, not a usage tutorial, and the cost of every design is written as plainly as its benefits.
Chapter One · Why Definition-Driven
What the problem is, where the paradigms diverge, and the case study's first appearance. This chapter sets side by side how many places one field touches under each paradigm.
- Day 1 · Why ERP Needs a Definition-Driven Framework
- Day 2 · An Overview of Definition-Driven Architecture
- Day 3 · The Northwind Case Study: Eight Forms and a Custom Business Object
Chapter Two · Definition Layer
What kinds of definition files there are, why their lifecycles differ, and how one structural description grows into the database structure, CRUD SQL, screens for multiple front ends and business rules.
- Day 4 · The Purpose and Classification of Definition Files
- Day 5 · How FormSchema Drives SQL
- Day 6 · TableSchema and Database Structure Upgrades
- Day 7 · FormLayout and Screen Generation for Multiple Front Ends
- Day 8 · Declarative Business Rules and Computed Fields
Chapter Three · Data Access and Caching
Without writing DTOs, how data crosses layers; the only two things multiple databases have in common; and how a cache knows its source has changed.
- Day 9 · Data and Definitions Split Apart, So Forms Need No Types of Their Own
- Day 10 · Multi-Database Support: CRUD and Structure Upgrades
- Day 11 · Connections, Transactions and Query Conditions in the Data Access Layer
- Day 12 · Cross-Node Invalidation for Definition and Data Caches
Chapter Four · Business Logic and API
Who takes over the part definitions cannot express, where the extension points open, and what a call passes through on its way from the caller to the business object.
- Day 13 · Session Management and Lifecycle
- Day 14 · Extension Points on a Business Object and When to Override Them
- Day 15 · API Contract Layering and the Type Registry
- Day 16 · JSON-RPC 2.0: Protocol Choice and the Request Pipeline
- Day 17 · The Connector and the Convergence of Client Responsibilities
- Day 18 · The Error Contract and User Visible Messages
Chapter Five · Multi-Tenancy and Customization
How one codebase lets every company look different without branching and without recompiling or redeploying. Where the customization work currently stops is stated plainly too.
- Day 19 · The Scope of the Customization Layer and Overlay Granularity
- Day 20 · Multilingual Customization and Resource Structure
- Day 21 · Business Logic Customization and the Four Plugin Stages
Chapter Six · Transport, Security and Audit
What data looks like when it is sent, which protections it passes through, who is allowed to call, and what can be looked up afterward.
- Day 22 · The Division of Labor Between XML, JSON and MessagePack
- Day 23 · The API Payload Security Pipeline: Order, Protection Levels and Keys
- Day 24 · The Three Axes of Permissions: Action, Row and Column
- Day 25 · The Audit Trail and the Before and After Values of a Change
Chapter Seven · Data Semantics
Amounts, quantities, dates and times of day: how the meaning of these values is kept from the definition all the way to the database, without any layer quietly changing it along the way.
- Day 26 · Numeric Semantics, Multiple Currencies and Units of Measure
- Day 27 · The Semantic Boundaries Between Date, DateTime and Time
- Day 28 · Time Zone Conversion of DateTime
Chapter Eight · Case Review and The Big Picture
The Northwind application examined item by item: which part definitions, the framework and application code each own. Then a single big picture, and the systems this design does not suit.
- Day 29 · Which Part Definitions, the Framework and Application Code Each Own
- Day 30 · Three Depths of Development and the Big Picture of the Framework
About the framework behind this series
The mechanisms discussed in the series are all built into an open source framework, bee-library. The case study is a separate repository, bee-northwind-avalonia, which pulls the framework in as a package and holds only the application's own definition files and code.
Update: Bee.NET (bee-library), the framework used when this series was written, has since been taken over by Polhem. The mechanisms carry over, the framework has been substantially refactored, and it is open source under the MIT license. The bee-library and bee-northwind-avalonia repositories are archived; type names and code in the posts follow bee-library as it was at the time of writing.
The framework's only role in this series is to show that these ideas are not just talk on paper. You can skip it entirely, take away only the idea of letting definitions be the source, and build that idea in the languages and tools you know.
📘 Original index on HackMD, in Traditional Chinese:
👉 https://hackmd.io/@jeff377/ironman-2026
📢 You are welcome to republish this, please credit the source.
📬 Follow for more engineering notes:
Facebook ｜ HackMD ｜ GitHub ｜ NuGet
Top comments (0)