What principles would you use to divide modules at a higher level than classes?

To divide modules at a higher level, I would use the following principles:

• By principles of encapsulation and cohesion (Cohesion & Coupling). Modules should be as self-sufficient as possible (high cohesion within the module) and have minimal dependencies on each other (low coupling between modules). This facilitates testing, understanding, and modifying the code.
• By functional area. Modules are grouped based on business logic or specific responsibility areas (e.g., user management, payment processing, notification sending).
• By architectural layers. In a multi-layer architecture (e.g., Presentation, Business Logic, Data Access), each layer can represent a separate module or a set of modules.
• By the Single Responsibility Principle (SRP) applied to modules. A module should have one reason to change. This is an extension of SRP to a larger scale.
• By the Principle of Least Privilege. Modules should only have access to the data and functionality they truly need.
• Considering future changes. The architecture should be flexible enough to accommodate potential development and changing requirements. Modules should be as independent from each other as possible to simplify the introduction of new features or modification of existing ones.
• Based on the frameworks and patterns used. The structure of a module can often be dictated or supported by the chosen framework (for example, in MVC, each V, M, C can belong to a separate module or group of modules depending on the scale) or architectural pattern (e.g., DDD - Domain-Driven Design, partitioning by aggregates).

These principles help create a more manageable, scalable, and maintainable application architecture.