How to handle a domain interacting with multiple infrastructure implementations

[chenjianpeng97]

Hi! I’m a test development engineer and I’m very interested in your repo. I want to apply this layered architecture to a real scenario:

I’m building an internal test case management platform. Test cases come from multiple sources/formats:

Markdown / Excel files (file I/O)
Existing ALM tools like ZenTao or Jira (API calls)
My own platform’s database (DB session)
Your layering approach seems attractive: define “test case” core logic in the domain, reuse the same application orchestration, and choose different adapters in the presentation layer (markdown/excel/api/db) that call different infrastructure implementations.

My confusion is about adapter selection. In your example, the application query service is bound to one concrete implementation during IoC registration. How should I handle multiple adapters?

Options I’m considering:

Define multiple gateways like TestCaseCsvGateway, TestCaseApiGateway, etc.
Add an adapter_type parameter to TestCaseQueryGateway and let IoC dynamically resolve the implementation at runtime(is that possible?).
Or is there a better engineering practice you recommend for this scenario?

Thanks for your time!

[ivan-borovets]

Hello, Tuner!

I'd start with a separate interactor for each use case step expressible in code, defining ports it needs. Unifying is possible, but I wouldn't rush it until I'm sure contract overlap isn't coincidental and components won't evolve independently.

If you need dynamic resolution, Dishka supports it via https://dishka.readthedocs.io/en/stable/advanced/when.html. Classic Strategy pattern is always an option too.