A module is a software unit that gathers related functionality into stateless functions, keeping those functions separate from the data entities they manipulate. In a library system, exposed operations such as searching, borrowing, returning, and blocking members form an API-facing module. section 2.0 section 2.3
Design a module by following these constraints:
- Aggregate related functionality, often beginning with the verb phrases in system requirements. section 2.3
- Keep every function stateless: pass the data it manipulates as an explicit argument instead of hiding state in the module. section 2.1 section 2.6
- Expose the functions required by the system’s external interface, while leaving internal functionality unexposed when appropriate. section 2.3
- Use module relations based on usage rather than inheritance, preserving a clear separation between code modules and data entities. section 2.4 section 2.6
Making state explicit
An object-oriented method might reach library state through an implicit receiver: getBookLendings(userId, memberId). A module function makes that state visible: getBookLendings(libraryData, userId, memberId). The function can then be considered independently from the data structure it receives. section 2.3 section 2.6
Use the Library module diagram to inspect how externally exposed functions are gathered into one high-level module. section 2.3
