coding design test

Prompt

You are being evaluated on **software architecture and design judgment**, not on how much code or explanation you can produce. Design a production-quality C#/.NET solution for the following problem: > Build a configurable processing platform that accepts work from multiple sources, routes each item through different processing strategies based on its type/configuration, applies validation and business rules, persists results, publishes optional downstream events, and supports future processing types and external systems without requiring modification of existing core logic. Assume requirements will evolve substantially over time and that different implementations may need to be substituted for testing, deployment, customer configuration, or future technology changes. Produce the **best architecture you believe is appropriate**. Do not mechanically apply patterns or create abstractions without a reason. Your design should demonstrate sound judgment around: * architectural layering and dependency direction * separation of concerns * domain/application/infrastructure boundaries * abstraction at appropriate seams * interface segregation * dependency inversion * strategy/policy selection * orchestration vs. implementation logic * isolation of external systems and infrastructure * configuration-driven behavior * extensibility without modification of stable code * testability * error/failure handling * observability * state and transaction boundaries * synchronous vs. asynchronous responsibilities * composition and dependency injection * avoiding unnecessary coupling * avoiding both under-design and over-engineering Use patterns such as Strategy, Factory, Adapter, Repository, Mediator, Pipeline, Decorator, Ports-and-Adapters, or others **only where they improve the design**. You are explicitly being evaluated on knowing when *not* to introduce a pattern. ### Output Keep narrative to a minimum. Provide: 1. **Architecture** * concise component/layer diagram * project/namespace structure * dependency direction 2. **Key design decisions** * only the most important decisions and tradeoffs * approximately 5–10 short bullets 3. **C# implementation** * enough compilable or near-compilable code to demonstrate the architecture * show the important interfaces, domain/application types, orchestration, strategy selection, infrastructure adapters, dependency injection/composition, and at least one alternate implementation * prefer representative code over boilerplate 4. **Extensibility demonstration** * show how a new processing strategy or external implementation can be added without modifying established core processing logic 5. **Testing seams** * provide a small unit test or test example demonstrating that core behavior can be tested independently of infrastructure Do not spend output explaining basic C# or design-pattern definitions. Do not assume that “clean architecture,” microservices, CQRS, DDD, repositories, or any other fashionable architecture is automatically correct. Make architectural choices from first principles and let the resulting code demonstrate the quality of the design.