ERP Architect's Notes: Designing a Definition-Driven Framework Series' Articles

Cover image for Day 1: Why ERP Needs a Definition-Driven Framework

Cover image for Day 2: An Overview of Definition-Driven Architecture

Cover image for Day 3: The Northwind Case Study: Eight Forms and a Custom Business Object

Cover image for Day 4: The Purpose and Classification of Definition Files

Cover image for Day 5: How FormSchema Drives SQL

Cover image for Day 6: TableSchema and Database Structure Upgrades

Cover image for Day 7: FormLayout and Screen Generation for Multiple Front Ends

Cover image for Day 8: Declarative Business Rules and Computed Fields

Cover image for Day 9: Data and Definitions Split Apart, So Forms Need No Types of Their Own

Cover image for Day 10: Multi-Database Support: CRUD and Structure Upgrades

Cover image for Day 11: Connections, Transactions and Query Conditions in the Data Access Layer

Cover image for Day 12: Cross-Node Invalidation for Definition and Data Caches

Cover image for Day 13: Session Management and Lifecycle

Cover image for Day 14: Extension Points on a Business Object and When to Override Them

Cover image for Day 15: API Contract Layering and the Type Registry

Cover image for Day 16: JSON-RPC 2.0: Protocol Choice and the Request Pipeline

Cover image for Day 17: The Connector and the Convergence of Client Responsibilities

Cover image for Day 18: The Error Contract and User Visible Messages

Cover image for Day 19: The Scope of the Customization Layer and Overlay Granularity

Cover image for Day 20: Multilingual Customization and Resource Structure

Cover image for Day 21: Business Logic Customization and the Four Plugin Stages

Cover image for Day 22: The Division of Labor Between XML, JSON and MessagePack