dylo takes a "module" crate and generates a "consumer" crate that knows how to build
and load that original crate — and that exposes the exact same public API.
"modules" are cdylibs library crates that only expose "dyn compatible" traits.
"consumers" are rlib library crates (the default) that usually have fewer dependency, and only export set of dyn-compatible traits, along with the struct/enum types used in the public API.
dylo relies on code generation: the dylo-cli tool looks for annotations from the dylo proc-macro crate, to know which "impl Trait for TraitImpl" blocks should be used to generate public traits.
Although that pattern is doable by hand, dylo takes a lot of the human error and repetitive work out of the equation.
To learn more, read the various crate documentation in order: