LXD is typically for system containers, Docker is usually an application container approach.
Application ContainersAn application container starts just the application inside the container context. No systemd, no sshd, no nothing -- except everything started by the application. And it is only one applications. For several applications, use separate containers and don't fold them into a single image.
This puts the focus on running application components (micro-service-style), and let's them run with the best agility available. This architecture makes it easy to replace and update components. Scaling a component is also facilitated by such a setup.
Docker and rkt from CoreOS are typical tools to run application containers.
System ContainersA system container runs an entire Linux system environment. That includes systemd and the rest of the daemons. As this feels more like individual Linux instances, the focus is on system instance management. It is a good lightweight replacement for genuine virtual machines, with higher density, but lower isolation capabilities. LXC/LXD from Canonical as well as systemd-nspawn are typical examples.
It is not uncommon to run application containers inside system containers; in fact Canonical suggests to use system containers are lightweight VM substitute (good for those setups with virtualization pain), and run an application container ecosystem like docker on top of it.
One disclaimer needs to be added here: the solutions mentioned (e.g. LXD and docker) are not fixed on their models: if you want, you can start docker containers with a systemd as the entrypoint, or use LXD for application containers. But why would you?