As a result, we reduced the amount of code, removed unnecessary duplication, and left only the essential code. We also opened ourselves up to further code refactoring (which we will discuss in the following sections):

1. We can now separate the structure building across different files and not drag them into a single one; for example, we can separately assemble configurations, database work, payment service clients, Kafka connections, etc.
2. We can assemble them in any order, not just in the order of initialization, which means we don't have to keep track of what was initialized first.
3. We can work with cyclic dependencies.

Testing Dependencies

The library resolves dependencies at runtime, as otherwise, it would be impossible to implement features like cyclic dependencies and arbitrary initialization order. This means that dependency resolution needs to be checked somehow, and for this purpose, a test should be added. This is done very simply. To do this, you just need to call the verify method. In general, it's enough to call it after the final assembly of dependencies. For example, like this:

```rust

use mydi::{InjectionBinder, Component};

fn build_dependencies(config: MyConfig) -> InjectionBinder<()> { todo!() }

[cfg(test)]

mod testdependenciesbuilding { use std::any::TypeId; use seaorm::DatabaseConnection; use crate::{builddependencies, config}; use std::collections::HashSet;

#[test]
fn test_dependencies() {
    let cfg_path = "./app_config.yml";
    let app_config = config::parse_config(&cfg_path).unwrap();
    let modules = build_dependencies(app_config);
    let initial_types = HashSet::from([  // types that will be resolved somewhere separately, but for the purposes of the test, we add them additionally
        TypeId::of::<DatabaseConnection>(),
        TypeId::of::<reqwest::Client>()
    ]);
    // the argument true means that in the errors, we will display not the full names of the structures, but only the final ones
    // if you are interested in the full ones, you should pass false instead
    modules.verify(initial_types, true).unwrap();
}

} ```

Modular Architecture and Composition

Organizing files and folders

How to organize a project with many dependencies? It may depend on your preferences, but I prefer the following folder structure:

- main.rs - modules -- mod.rs -- dao.rs -- clients.rs -- configs.rs -- controllers.rs -- services.rs -- ...

This means that there is a separate folder with files for assembling dependencies, each responsible for its own set of services in terms of functionality. Alternatively, if you prefer, you can divide the services not by functional purpose, but by domain areas:

- main.rs - modules -- mod.rs -- users.rs -- payments.rs -- metrics.rs -- ...

Both options are correct and will work, and which one to use is more a matter of taste. In each module, its own InjectionBinder will be assembled, and in main.rs, there will be something like:

```rust

use mydi::{InjectionBinder, Component};

[derive(Component, Clone)]

struct MyApp {}

impl MyApp { fn run(&self) { todo!() } }

fn mergedependencies() -> Result> { let result = modules::dao::builddependencies() .merge(modules::configs::builddependencies()?) // Of course, during dependency assembly, something might fail .merge(modules::clients::builddependencies()) .merge(modules::services::builddependencies()) .merge(modules::controllers::builddependencies()) .inject::(); Ok(result) }

fn main() -> Result<(), Box> { let injector = merge_dependencies()?.build()?; let app: MyApp = injector.get()?; app.run(); Ok(()) }

```

Organizing a separate module

So, how will the modules themselves look? This may also depend on personal preferences. I prefer to use configurations as specific instances.

```rust use mydi::InjectionBinder;

pub fn builddependencies(appconfigpath: &str, kafkaconfigpath: &str) -> Resultconfig = AppConfig::parse(appconfigpath)?; let kafkaconfig = KafkaConfig::parse(kafkaconfigpath)?; let result = InjectionBinder::new() .instance(appconfig) .instance(kafka_config) // ... .void();

Ok(result)