That sounds correct. However, you're very flexible in who composes the transaction and who actually submits it to the network.
In general at some point a transaction needs to be signed by the end user's wallet (which holds the private key to your funds) - and this is the step that requires some sort of interface that is the DApp connector (possibly also to identify the user by the public address in the first place).
Regarding the client and server side of DApps, there is no single architecture that fits all use cases.
You can have a setup in which 1) the client passes its public address to the server, which then 2) generates a transaction, 3) passes it to the client for signing; 4) the client passes it (or even only the "signature" for this tx) back to the server for 5) final verification & server-side signing, before the server then 6) submits it to the network.
On the other hand a DApp strictly doesn't need a server at all, and everything could happen on the client side (eg in the browser through a lib like this https://www.npmjs.com/package/@emurgo/cardano-serialization-lib-browser) - you can generate your transactions and submit them to the network through a wallet's dapp connector (eg using Nami wallet https://github.com/Berry-Pool/nami-wallet).
(A transaction is composed of a body, the witness set and optional metadata. The witness set holds the "signatures" of the different parties required to submit the transaction - thats how you can pass these parts around, compose them modularly, store them for later use / server side verifications etc. between clients and server)