Question: I am trying to understand things like linkers and loaders better.

What area of computer science do they belong to? Compiler, Operating System, Computer Architecture?

Where do linkers and loaders come into play during development?

Answer: 
Linkers and loaders are two related but separate concepts.

Linkers are a part of compiler theory. When you compile a project made up of more than one module (source code file), it's common for the compiler to output a single intermediary file for each source module. This has several benefits, one of which is that if you only make changes to one file and then have to recompile, you don't have to rebuild the entire project when you've only made one local change.

But this means that if you have code in one module that calls a function in a different module, the compiler can't generate a `CALL` instruction to it, because it doesn't have the location of that other function. It's in a different intermediary file, and the exact location of the function can change if you make a local change to that intermediary's source file and recompile it. So instead, it inserts an "external reference token" (exactly what that is or what it looks like doesn't matter, just think of it as an abstract concept) that says "I need this function whose exact address I don't know at the moment."

Once everything has been compiled into intermediary files, the linker is what finishes the job. It goes through all the intermediary files and links them together into a final binary. Since it's putting things together, it does know the actual addresses of all the functions, and so it can replace the external reference tokens with actual `CALL` instructions to the correct locations in the binary.

The loader, on the other hand, belongs to the operating system, not the compiler. Its job is to load the binary into memory so it can execute, and to finish up the linking process, since the linker can only resolve code it knows about. If your program is using any DLLs, they are external even to the compiled binary, so the linker doesn't know their address. It leaves external reference tokens in the final binary in a format that the OS's loader knows about, and then the loader goes through and matches these tokens to the actual function addresses in the DLLs once everything has been loaded into memory.
To find out more about linkers, I think they'll generally be discussed in combination with compilers. They are for knitting your various modules together into a cohesive unit, finalizing addresses within that code. Some may even try to perform optimizations.

To find out more about loaders, I think they'll generally be discussed in combination with writing compilers for particular architectures unless you mean loader as a synonym for linker. I'm thinking of the loader as the part of the executable file header that tells the operating system how to open and execute your compiled software.

I agree that reading the Wikipedia articles will probably impart more information than you're looking for. As to where they come into development ... generally they are beyond the control of the project, and are part of the selection of the operating system and the development package you choose to use. It's very rare that you would use (for example) MSVC but want to run a GCC based linker ... might not even be possible. The ONLY place I've ever used a non-standard linker was at IBM when we were using development copies.

If you have more particular, specific questions about these topics, I think you'll find a much better response.