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

Security