Logic thread between output folders and input transactions I'm studying the bitcoin protocol and I don't have very clear things, for example the logical thread that exists between an output transaction and a subsequent input transaction, where that output is direct.

I realized that the input transaction contains the reference to the output transaction through the Outpoint type, but now how could the input transaction related to the output transaction be identified?

an example

Bob sells a coffee to Alice and Alice pays in bitcoins, then bob spends his input transaction coming from the alice output transaction, Now I want to find and the two Rawtransactions where the alice transaction information and the bob information are contained for connect the two RawTransactions.
I believe that I haven't understood any important steps to do this

Sorry for my terrible English but I'm learning
Let us illustrate this using the example given in Mastering Bitcoin.

Joe sent 0.1 BTC to Alice in the transaction having txid = 7957a35fe64f80d234d76d83a2a8f1a0d8149a41d81de548f0a65a8a999f6f18. Below are the outputs of that transaction:

vout": [
    {
        "value": 0.10000000,
        "n": 0,
        "scriptPubKey": {
            "asm": "OP_DUP OP_HASH160 7f9b1a7fb68d60c536c2fd8aeaa53a8f3cc025a8 OP_EQUALVERIFY OP_CHECKSIG",
            "hex": "76a9147f9b1a7fb68d60c536c2fd8aeaa53a8f3cc025a888ac",
            "reqSigs": 1,
            "type": "pubkeyhash",
            "addresses": [
                "1Cdid9KFAaatwczBwBttQcwXYCpvK8h7FK"
            ]
    }
]


When Alice spends these earnt bitcoins to Bob Cafe, she references this transaction in the input. Note that the input includes the txid of the transaction through which she earnt her bitcoins and the n=0 which shows output number of that transactions that was directed to the address she controls.

"vin": [
        {
            "txid": "7957a35fe64f80d234d76d83a2a8f1a0d8149a41d81de548f0a65a8a999f6f18",
            "vout": 0,
            "scriptSig": {
                "asm": "3045022100884d142d86652a3f47ba4746ec719bbfbd040a570b1deccbb6498c75c4ae24cb02204b9f039ff08df09cbe9f6addac960298cad530a863ea8f53982c09db8f6e3813[ALL] 0484ecc0d46f1918b30928fa0e4ed99f16a0fb4fde0735e7ade8416ab9fe423cc5412336376789d172787ec3457eee41c04f4938de5cc17b4a10fa336a8d752adf",
                "hex": "483045022100884d142d86652a3f47ba4746ec719bbfbd040a570b1deccbb6498c75c4ae24cb02204b9f039ff08df09cbe9f6addac960298cad530a863ea8f53982c09db8f6e381301410484ecc0d46f1918b30928fa0e4ed99f16a0fb4fde0735e7ade8416ab9fe423cc5412336376789d172787ec3457eee41c04f4938de5cc17b4a10fa336a8d752adf"
            },
            "sequence": 4294967295
        }
    ],


Full nodes maintain a UTXO set through which they can easily cross-verify this data to ensure, the txid and n referenced by Alice has not been spent previously. If Alice wanted to spend more than 0.1 BTC to Bob Cafe, she would have had to reference multiple transactions as the txid and n she referenced only has access to 0.1 BTC.