- Architecture { Design is Goals dependent }
- Criteria {
- Speed (SLA defined Load Times)
- Availability (SLA defined Minimum Uptime)
- Load Balancing
- Redundancy (at Application Layer)
- Failover Warm Standby (at DB Layer)
- Scalability
- Fault-Tolerant (core functionality unaffected by downtime of non-critical)
- Reliability (Reprovisioning without downtime)
- Source Control (version control)
- QA cycle (test releases and issue tracking before production)
- Deployment Procedure
- Error Logging (real-time notification)
- Backups (failover DB)
- Performance tuning (Schema design)
- Statistics (Data collection and analysis exposing weak points and driving strategy)
- System Components (Independent, Isolated, Encapsulated) and and Services are unconcerned with inner workings of other Services or Front-End
- Web-Services Layer
- Complexity Strategies (at Firewall)
- Services accessible publicly for integration with other apps by Third Party Developers (Usage Restrictions, Authentication, Encryption) whilst F-E Site also accessible via Browser
- Application Layer (Front-End, Services)
- Encapsulated Services { Data Abstraction with DB access behind Services separate from consuming Front-End }
- Asynchronous Processes { Queues (Enterprise Service Bus) of info messages from Services
- Horizontal Scaling { Services split into manageable parts with Functional responsibilities across team after breakdown of large App }
- Data Warehouse fed by each Service DB (reporting and decision support)
- Complexity Strategies (within Firewall) including Service-Oriented Architecture (SOA)
- Multiple F-E & Single B-E Service { Front-End for different Business Models with multiple UIs and Feature sets (to Target Audience) that communicate over network with single Content Management Service, each with Shared underlying Content Data Structure }
- Single F-E & Multiple B-E Services { Services separated with specific API (Service API) for their feature set of major Functionality and Data Layers that are consumed by F-E UI or other Service APIs
- Persistence (DB) Layer { RDBMS persists storing and protecting the integrity of business data until changed or removed with ACID-compliant DB guarantees and properly designed Database Schema }
- Atomicity { Group statements into Single Transaction (Atomic Units) with Success or Failure (without interruption leaving Invalid Data) using .transaction method on Model Class }
- Consistency { Constraints defined Before and After Transactions with different tolerance for inconsistency }
- Isolation { Prevent access to data during Transaction Process before it is finished (when it is inconsistent) }
- Durability { Speed versus Reliability }
- Web Services Layer (External Interface)
- External Clients provided subset of inner Functionality
IN PROGRESS
No comments:
Post a Comment