Software Development Principles & Glossary
Project Software Development Principles
Software Development Principles & Glossary
Appendix: Core 18 Software Engineering Principles for Staffing Pipeline Version: 1.0
1. SoC — Separation of Concerns Separate different responsibilities into distinct layers/modules. One layer handles only its own domain logic without crossing boundaries.
Example: Email parser only extracts data, never performs candidate matching or SMS sending.
2. SRP — Single Responsibility Principle (SOLID #1) A class or function shall have only one reason to change. A component owns exactly one job.
Example: parseTffStaffingEmail.js only parses email content, it does not write to database.
3. MVP — Minimum Viable Product Build the smallest usable release that completes the full end-to-end business workflow. Exclude non-essential optimizations for later iterations.
4. DRY — Don’t Repeat Yourself Avoid duplicate code. Extract shared logic into reusable shared packages to reduce maintenance cost.
Example: Candidate eligibility validation extracted into shared @wfm/job-assignment library.
5. KISS — Keep It Simple, Stupid Prefer simple, straightforward implementations. Avoid over-engineered complex solutions unless required. 6. YAGNI — You Aren’t Gonna Need It Do not implement features that are not required for current requirements. Delay speculative future functionality. 7. Idempotency Repeating the same operation multiple times yields identical result as executing once. Prevent duplicate records or duplicate SMS dispatches.
Protect against reprocessing the same supervisor email multiple times.
8. Atomicity (ACID) Database transactions are all-or-nothing. Either all changes commit successfully, or everything rolls back.
9. Loose Coupling Modules communicate via well-defined contracts/interfaces. Internal changes of one module do not break dependent modules.
Contrast: Tight coupling means components directly depend on internal implementation details.
10. Fail Isolation Failure of one independent work item must not abort the entire batch workflow.
Example: One failed AiJobFillRequestLine does not stop processing remaining lines in the same request.
11. Fail Fast Validate inputs and constraints early. Throw errors as soon as invalid data is detected instead of failing deep inside business logic. 12. Stateless Service runtime does not store session data in memory. All state is persisted in database, supporting horizontal scaling. 13. Event-Driven Architecture Decouple downstream consumers by publishing events after business state changes. Subscribers consume events without direct function calls.
Example: Publish PlacementCreated event after candidate accepts invitation for payroll/report consumption.
14. Boundary Context (DDD) Define clear domain boundaries. Split system into bounded contexts such as Candidate, Staffing Request, and Outbound Communications.
15. E2E — End-to-End Testing Test the complete business flow from entry trigger to final outcome, not isolated individual functions.
Our SMS invitation test from incoming email to confirmed placement is an E2E test.
16. Regression Testing Run validation after code changes to ensure existing working features are not broken by new modifications. 17. Backpressure Control ingestion/processing rate under high load. Prevent database or external API overload from sudden traffic spikes. 18. Contract / Interface Driven Development Define fixed input/output schemas for module integration. Consumers depend only on the contract, not internal implementation details.
Compact Quick Reference Table
markdown
| Abbreviation | Full Name |
|---|---|
| SoC | Separation of Concerns |
| SRP | Single Responsibility Principle |
| MVP | Minimum Viable Product |
| DRY | Don’t Repeat Yourself |