Sample showing how you can use splatting to create a DSL for config data to drive a script

gistfile1.ps1

# This is the public script we call as an entry point into the deployment / configuration process
Function Invoke-Deployment
{
    Param
    (
        $ApplicationPool,
        $WebSite
    )
    
    Invoke-AppPoolTasks @PSBoundParameters
    Invoke-WebSiteTasks @PSBoundParameters
}

# The main script for managing ApplicationPools
Function Invoke-AppPoolTasks
{
    Param
    (
        # this is essentially a hashtable that contains all the properties we need
        # we can then use PS dot notation to step into the property we want to access
        # as if we had a fully fledged object model
        $ApplicationPool 
    )
    
    Write-Host $ApplicationPool.Name
}

# The main script for managing WebSites
Function Invoke-WebSiteTasks
{
    Param
    (
        $WebSite
    )
    
    Write-Host $Website.Name
    Write-Host $Website.ApplicationPoolName
    
    # we can access each property manually, for example $Website.Bindings[0].Ip or by looping
    foreach($binding in $Website.Bindings)
    {
        Write-Host ("{0}:{1}:{2}" -f $binding.Ip, $binding.Port, $binding.HostName)
    }
}

# We can define a stronger object model, which is essentially dynamic and easy to extend
$parameters = @{
    ApplicationPool = @{ 
        Name = "Endjin_Web_App_Pool" 
    }
    WebSite = @{ 
        Name = "Endjin_Web"
        ApplicationPoolName = "Endjin_Web_App_Pool"
        Bindings = @( 
            @{ 
                Ip = "192.168.100.10"
                Port = "80"
                HostName = "endjin.com"
            },
            @{ 
                Ip = "192.168.100.10"
                Port = "443"
                HostName = "endjin.com"
            }
        )
    }
}

Clear-Host
Invoke-Deployment @parameters