Verdict

“Centralizing validation improves maintainability, but the architectural reversal (infrastructure referencing application) is already common, so differentiation is modest.”

The core idea—centralizing HTTP validation in a dedicated service and moving the HttpClient call to the infrastructure layer—addresses duplication and improves testability, which are common refactoring goals. However, the architectural pattern of defining interfaces in the application layer and implementing them in infrastructure is already well‑established in Clean Architecture, Onion, and Hexagonal architectures, and many ASP.NET Core projects follow the same dependency direction (infrastructure depends on abstractions defined in inner layers). Therefore, while the solution is sensible and can be durable if properly encapsulated, it does not provide a strong, unique differentiation from existing approaches; the main benefit is reduced duplication rather than a novel competitive advantage.

“The infrastructure layer referencing the application layer is acceptable in this case because it's implementing a contract defined by the application layer.”

The proposed solution to extract the repeated validation logic into a shared application service is feasible and follows good practices. Creating an interface in the application layer and its implementation in the infrastructure layer is a suitable approach to handle the HTTP dependency. The concern about the infrastructure project referencing the application project is valid, as it inverts the traditional dependency direction. However, in this case, it's justified because the infrastructure layer is implementing a contract defined in the application layer. The key challenge lies in ensuring that the infrastructure layer correctly maps the HTTP call result to the application response type. Overall, a solo or 2-person team can build this solution within 4-12 weeks, as it involves refactoring existing code and applying established design patterns.

“Clean Architecture allows Infrastructure to reference Application — but without a paying customer or revenue model, this is an engineering optimization, not a business venture.”

Your proposed architecture is technically sound and aligns with Clean Architecture principles: interfaces in Application, implementations in Infrastructure, and avoiding HTTP dependencies in UseCases. The concern about Infrastructure referencing Application is misplaced — in Clean Architecture, dependencies point inward, so Infrastructure (outer layer) can and should reference Application (inner layer) to implement interfaces defined there. This is standard practice in enterprise systems. The real win here is eliminating duplicated validation logic via a shared Application service, which improves maintainability and testability. However, the score is not higher because the idea lacks a clear business problem or market need. This is a technical refactoring question, not a business venture. There’s no indication of a paying audience, revenue model, or customer pain point being solved. Investors or customers don’t pay for ‘better architecture’ — they pay for faster features, lower costs, or new capabilities. Without tying this refactoring to a measurable business outcome (e.g., ‘reducing API failure rates by 40% which cuts customer support costs by $X/year’), this remains an internal engineering improvement. If this were part of a product offering — like a SaaS platform that guarantees high API reliability — then the score would be 9+. As-is, it’s a solid technical decision with zero market demand attached.

“Proposed dependency reversal compromises Clean Architecture principles, risking architectural entanglement and maintainability issues.”

The proposed solution introduces a circular dependency risk by having Infrastructure reference Application, violating traditional layer independence. This breaks the Clean Architecture principle of directional dependency (Inner layers should not depend on Outer layers). While the intention to reduce duplication and improve testability is sound, the implementation approach significantly increases architectural risk. The dependency reversal (Infrastructure → Application) sets a precarious precedent, potentially leading to a tangled web of dependencies as the project grows. Furthermore, placing response objects in the Application layer may still blur domain boundaries if not carefully managed. **Failure Modes within 6-12 months:** 1. **Architectural Entanglement**: Dependencies become intractable, hindering maintainability and scalability. 2. **Testing Complexity**: Increased inter-layer dependencies complicate unit testing isolation. 3. **Domain Leakage**: Non-domain concerns (external response objects) pollute the Application layer, obscuring core business logic.

“Infrastructure referencing Application is correct when implementing interfaces defined in Application for outer-layer concerns.”

Your proposed architecture aligns well with Clean Architecture principles by isolating HTTP dependencies in Infrastructure and defining contracts (interfaces + DTOs) in Application. This avoids polluting Domain with external concerns while maintaining testability. The Infrastructure → Application reference is valid: Infrastructure (outer layer) can depend on Application (inner layer) to implement interfaces defined there. Centralizing the validation logic in an Application service reduces duplication without violating SRP, as the service is a shared utility, not a UseCase. The trade-off is a slight coupling between Infrastructure and Application, but this is acceptable since Infrastructure exists to serve Application. Unit testing remains clean via interface mocking, and Domain stays pure. The only minor risk is overloading Application with too many external contracts, but your use case justifies it.