Philosophy & Design Goals
- Prepare applications for the next 30 Years
- Don't Rewrite. Re-Think, Re-Invent and Re-design
- Reproduce the capabilities of Classic.
- The "What", not the "How". What it does is the same. How it's done is different.
- Implement minimum business rules. Leave the rest to customization
Technical Architecture
- One Database per District per Application
- One installation of the software per District
- Ready for the "Cloud"
Application Architecture
Modules
- Independent Installable Features
- Types of Modules:
- Infrastructure (database, email)
- Behavioral (business logic)
- Required
- Optional (authentication)
Data Model
- Object Oriented
- Abstraction of underlying Database tables
- Simplifies tables
- Correctly linked to related objects
- Dynamic
- Primary key
- Immutable
- Random UUID
- Natural Id
- User/Auto assigned identifier
- May be mutable
- Not used in relationship
- https://usas.docs.ssdt.io/current/model/
- https://usps.docs.ssdt.io/current/model/
Database Transactions
The Classic Problem
- If operation fails (due to crash):
- USxS transaction can be partial posted
- Files left in inconsistent state (out of balance)
- Example: Post Purchase Order:
- Write PO header record
- Loop for each PO Item:
- Write item record
- Update encumbrances on budget
- Update encumbrances on appropriation
- Update encumbrances on cash
The Redesign Solution
- SQL Databases provide "Transactional Scope"
- All operations within scope guaranteed to, either:
- Succeed completely (commit)
- Fail completely (rollback)
- Any error causes rollback:
- Duplicate key
- Validation error
- Security violation
- System failure
Transactions, Events, Processing, Listeners & Rules