I can't speak to Keil uVision. It's been many years since I used Keil. But I can talk, generally.
An assembler usually produces an object file. This is a custom formatted file that typically is composed of a series of records that contain symbols, strings of code bytes, strings of initialized data, and section information. (A lot more than that, but that's a quick summary.) An object file is not particularly useful until after a linker processes it. But it is very useful to the linker.
(It's possible -- and some do this -- for an assembler to directly generate binary code, which may either be directly usable by a loader program or else can be directly written to ROM. But this isn't possible if there is more than one source file being assembled one at a time by the assembler. And that's the case you are asking about.)
The assembler can be applied to source files, one after another, until all of the source files have been turned into object files. Then, usually, the linker is given the names of all these object files, along with a linker input file that adds the remaining information needed to allocate memory from the right places and then build a file that is compatible with the loader program or used to place data into a ROM. The linker input file (or the command line) may also specify default library code and data to use, if necessary.
Symbols in an object file can have global or local file scope. If local file scope, then the linker will only recognize references to that symbol name within the source file it's processing at the time. If global scope, then the linker will match up these names across all of the object files and consider them to be the same throughout the program unit. The assembler will have syntax to allow either choice and, likely, a default if you don't specify which of the two.
Symbols can either be labels associated with code (for branching instruction targets) or be associated with data memory. The linker is well aware of such differences and won't mix them up.
Also, code and data can be grouped into named-groups and these named-groups can be combined into sections. The sections can be located at specific memory addresses, using the linker input file. How much detailed control over locating code and data (whether or not groups can themselves be located, or sections only) is a matter for the specific linker.
The only way you can wield multi-file projects like a professional is to study other projects and to practice, a lot, writing your own code.
