Since DSC resources are PowerShell modules, it is easy to use their built-in discovery methods to share functions and other code artifacts between DSC resources. You must resist overusing this approach, as it can bite you as time goes on. Let's say two DSC resources called ExampleResource1 and ExampleResource2 are in the same module called ExampleFooResource. ExampleResource1 has a function that ExampleResource2 borrows to retrieve the same information in order to do its work.

We've created a dependency, which is now our responsibility to uphold for the life of the DSC resource. If we change the function in ExampleResource1, it has to change in ExampleResource2 too. If we don't have some way of tracking this dependency, it can be become hard to troubleshoot how to break this dependency until the DSC resource is used. If it is a lesser-used function and we don't have a testing practice set up, it could be quite some time before we find out the breakage. While this is not optimal, if you had to copy and paste the code instead of reusing it, you would have to deal with updating code in several files whenever you fixed a bug or updated a functionality.

The point being made here is to be aware of the trade-offs when you develop DSC resources.