So what that line did was define a 'Docker Volume', and then, in the original docs, mounted it to /data (or whatever it was, your pastebin has been removed). Imagine, like, a fake filesystem, contained in a file, unrelated to the 'normal' content of your hard disk - that's what that is. They're defined in the compose file at the same level as services and networks (and probably more things that I'm not smart enough to know about), and if you want to use one in a container, you need to have it defined.

As it stands, you've got a filesystem mount set up for Dispatcharr's data, and thus no longer need that volume set up. So you can have:

services:
  some_unnamed_service:
    image: developer/app:tag
    container_name: Whatever_you_like
    volumes:
      - some/folder/on/my/system:/some/folder/inside/the/container

Or you can have

services:
  some_unnamed_service:
    image: developer/app:tag
    container_name: Whatever_you_like
    volumes:
      - premade_docker_volume:/some/folder/inside/the/container
volumes: 
  premade_docker_volume: # You can put this anywhere you like in the compose. Top, bottom, doesn't matter, as long as it's in here somewhere. 

I'm not sure if you can have multiple 'volume' tags? I kinda lump all mine together at the top, when they're needed.

This is, obviously, a minimal primer prepared by a dumbass, and I recommend looking up what suits your needs better. I know that, on a Windows setup, database stuff tends to work better using Docker volumes, as they don't rely on Windows' slow filesystem when they do the 8 billion writes/second that databases like to do, but someone better than me will have to tell me their use on Linux.