Design Checklist #
This article is intended to discuss the basic functionality that every developer and project manager should consider when developing software.
By consolidating this information into a checklist, it becomes easier to ensure that critical steps and considerations are not skipped or forgotten during the process of designing, developing, and deploying software. This allows development teams the ability to focus on the challenge of delivering business functionality while still ensuring that we have a safe, scalable, and performant product portfolio.
Please keep in mind that every environment, product, and situation is different. These checklists should always be read with “…if applicable” implicitly added.
Architecture and Design #
| Architecture and API Design Considerations |
References |
| Service functionality is inherently stateless. |
|
| Version strategy is defined, documented, and implemented. |
|
| System designed to gracefully degrade. |
|
| API Rest Standards are being followed throughout. |
|
| All entry points and trust boundaries are clearly identified and addressed. |
|
| There are clear divisions between external and interal interfaces. |
|
| Design assumes malicious callers. |
|
| All remote resources are called asynchronously if possible. |
|
| Security review has been completed on the design |
|
Documentation #
| Documentaation Considerations |
References |
| Any API Contracts are fully defined and published |
|
A core documentation folder (docs) exists in the code containing anough information to get a new developer up and running with a basic understanding of the system / service functionality and its interactions with other items in the suite. |
|
| There are documentated samples of all resources. |
|
Current VERSION.MD file exists in the docs folder. |
|
| All assumptions have been documented clearly along with any implications |
|
| All services have OPENAPI 3.0+ documentation published |
|
Monitoring and Logging #
| Monitoring and Logging Considerations |
References |
| At a minimum, all exceptions are logged. |
|
| At a minimum, all boundary methods have measures applied to them. |
|
| No sensitive data is logged. |
|
| Correlation ID’s are used whenever possible to allow for tracing across operations and systems |
|
| All log events are sent to the SpheraCloud Logging framework |
|
Communication & Enternal Resources #
| Communications and External Resources Considerations |
References |
| SSL everywhere - all the time. NO exceptions |
|
| All data is encrypted at rest |
|
| All return fields can be limited / sorted / filtered |
|
| Any necessary throttling has been identified and implemented |
|
| Latency and response SLA’s have been identified and documented along with appropriate mesasures to monitor them |
|
| Bulkhead strategies employed against external resources |
|
| Circuit-breaker strategies employed against external resources |
|
| GET, HEAD, PUT, DELETE, OPTIONS, and TRACE are all idempotent |
|
| JSON reposnse supported for all resources |
|
| Proper HTTP response codes are returned |
|
| Performnace and Testing Considerations |
References |
| No unnecessary dependencies |
|
| Unit test cases exist and code coverage is > 90% |
|
| Code has been tested to gracefully handle ALL external errors |
|
| All resources are released when no longer required |
|
| Service / code performance has been validated over the defined target range |
|
| Auto-scaling functionality has been tested and clearly documented |
|
