PO
PowerShell Module Architecture
PowerShell module design patterns for reusable, maintainable script libraries
Details
Language / Topic
PowerShellCategory
Architecture
Rules
balanced
- Package reusable code as a PowerShell module with a `.psd1` manifest and a `.psm1` root module — use `Export-ModuleMember -Function` to control the public API.
- Use a `Public/` and `Private/` folder structure inside the module: dot-source public functions in the `.psm1` and keep private helpers invisible to consumers.
- Version modules with `ModuleVersion` in the manifest and use `RequiredModules` to declare dependencies — never rely on implicit module loading order.
- Use `class` definitions (PowerShell 5+) for complex data types instead of `[PSCustomObject]` when you need methods, inheritance, or type-checked properties.
- Keep each public function in its own file named `Verb-Noun.ps1` under `Public/` — this makes navigation, code review, and git history easier.
- Use module-level `$script:` scoped variables for shared state rather than global variables — `$global:` leaks state between modules and test runs.
- Document the module with comment-based help on every exported function so `Get-Help MyModule` works without reading source code.