Clean Architecture applied to 3D validation systems with AI

By Aitor Nain Mendoza Vallejo ·August 19, 2026

You are leading an ambitious engineering team. You have integrated artificial intelligence models capable of generating and analyzing 3D meshes at incredible speeds. The product works in testing, the management is excited, but as a Software Architect or CTO, you know there is an underlying problem: the code is a ticking time bomb.

Industrial-scale 3D model validation (geometries, mesh analysis, ML inference) is intricate. When engineers directly couple the geometric engine logic (like Unity or CAD tools) with AI inference services and business rules, the result is a spaghetti monolith. Updating the AI model version or changing how the files .obj or .glb are stored breaks cryptic validations miles away in the code.

Why do traditional monolithic approaches fail here? Because in the domain of 3D and AI, the infrastructure is extremely volatile. Today you use a specific LLM/Vision provider, tomorrow the company decides to train its own model. Today you use a render engine, tomorrow you move to the cloud.

The Dilemma: Scalability vs. Maintainability in AI-Powered 3D Systems

Every CTO facing data-intensive systems (like massive 3D model processing via AI) hits the same dilemma. On one hand, you need raw scalability: parallelizing inference, utilizing GPUs, reducing geometric analysis latency. On the other, you need absolute maintainability: ensuring that a faulty mesh doesn't make it to production because a change in the HuggingFace or OpenAI API altered the expected response format.

In my experience auditing enterprise architectures, I have seen systems where the business logic (Does this 3D model meet the allowed collision tolerances?) was written inside the same REST controller that received the request, calling the embedded Python SDK directly. This is not just technical debt; it is a critical business risk.

“Software architecture is the art of drawing lines that separate what matters from implementation details. In AI and 3D, the Machine Learning model is just a detail.”

Clean Architecture as the Definitive Solution

To resolve this coupling crisis, we must apply the principles of Clean Architecture (proposed by Robert C. Martin). The core concept is the Dependency Rule: source code dependencies must always point inward, toward the high-level policies (business rules).

In the context of 3D validation with AI (you can see an implementation example in the backend architecture for 3D validation in C#), this means that our rules on what constitutes a 'valid' mesh should know absolutely nothing about how the AI runs, where the data comes from, or what web framework we use to expose the service.

The Four Layers in Our Context

• Domain (Entities): Contains the pure definition of our business objects. A class MeshGeometry, rules regarding error tolerances, or Vertex/Polygon structures independent of any external library.
• Application (Use Cases): Coordinates the data flow. Use cases like ValidateMeshUseCase or DetectAnomaliesUseCase live here. This layer dictates what must happen, but delegates the how to the next layer via interfaces (Ports).
• Infrastructure (Adapters): The “real world.” Here we implement the interfaces defined in the Application layer. We will have adapters such as TensorFlowInferenceEngine, AwsS3MeshStorage, or a BlenderGeometryAnalyzer.
• Presentation (Delivery): The system's entry points. REST Controllers (ASP.NET Core), RabbitMQ queue subscriptions, or gRPC integrations for microservices.

Practical Example: Implementation in C# / .NET

Let's see how this translates to a real, product- and business-oriented structure using C#. We will design the system based on the principle of Single Source of Truth, where the backend is the absolute brain.

1. Project Structure

Src/
├── 1.Domain/
│   └── GeometryValidator.Domain/
│       ├── Entities/
│       │   ├── MeshModel.cs
│       │   └── ValidationResult.cs
│       └── Exceptions/
│           └── InvalidGeometryException.cs
├── 2.Application/
│   └── GeometryValidator.Application/
│       ├── Interfaces/
│       │   ├── IAiInferenceService.cs  // Puerto de salida (Outbound)
│       │   └── IMeshStorage.cs         // Puerto de salida (Outbound)
│       └── UseCases/
│           └── ValidateMesh/
│               ├── ValidateMeshCommand.cs
│               └── ValidateMeshUseCase.cs
├── 3.Infrastructure/
│   └── GeometryValidator.Infrastructure/
│       ├── AiEngines/
│       │   └── PyTorchInferenceAdapter.cs // Implementa IAiInferenceService
│       └── Storage/
│           └── AzureBlobStorageAdapter.cs // Implementa IMeshStorage
└── 4.Presentation/
    └── GeometryValidator.Api/
        └── Controllers/
            └── ValidationController.cs

2. Defining the Domain (Incorruptible)

Our entity knows nothing about databases or AI. It only knows the pure business rules.

// Capa: Domain
public class MeshModel
{
    public Guid Id { get; private set; }
    public int VertexCount { get; private set; }
    public int PolygonCount { get; private set; }
    public bool IsWatertight { get; private set; }

    public MeshModel(Guid id, int vertices, int polygons, bool isWatertight)
    {
        if (vertices < 3) throw new InvalidGeometryException("Malla inválida: insuficientes vértices.");
        
        Id = id;
        VertexCount = vertices;
        PolygonCount = polygons;
        IsWatertight = isWatertight;
    }

    public bool ExceedsComplexityThreshold(int maxPolygons) 
        => PolygonCount > maxPolygons;
}

3. The Use Case (Orchestrator)

The Use Case controls the flow. It requests the mesh from storage, applies domain rules, and then uses the AI service (through an abstraction) to search for complex anomalies.

// Capa: Application
public class ValidateMeshUseCase 
{
    private readonly IMeshStorage _storage;
    private readonly IAiInferenceService _aiInference;

    public ValidateMeshUseCase(IMeshStorage storage, IAiInferenceService aiInference)
    {
        _storage = storage;
        _aiInference = aiInference;
    }

    public async Task<ValidationResult> ExecuteAsync(ValidateMeshCommand command)
    {
        // 1. Recuperar el modelo 3D crudo
        var rawMesh = await _storage.GetMeshAsync(command.MeshId);
        
        // 2. Construir la entidad de dominio (reglas de negocio básicas)
        var meshEntity = new MeshModel(
            command.MeshId, 
            rawMesh.Vertices, 
            rawMesh.Polygons, 
            rawMesh.IsWatertight
        );

        // 3. Validación de negocio rápida
        if (!meshEntity.IsWatertight)
        {
            return ValidationResult.Failed("El modelo debe ser cerrado (watertight).");
        }

        // 4. Delegar a la IA para detección de anomalías topológicas avanzadas
        // Nótese que NO sabemos qué IA corre debajo. Solo confiamos en el contrato.
        var aiReport = await _aiInference.DetectAnomaliesAsync(rawMesh.DataStream);

        if (aiReport.HasCriticalErrors)
        {
            return ValidationResult.Failed($"IA detectó errores: {aiReport.Summary}");
        }

        return ValidationResult.Success();
    }
}

4. The Infrastructure Adapter

This is where we handle volatility. If OpenAI changes its API, or if we decide to move to a locally hosted model with ONNX, we only touch this file.

// Capa: Infrastructure
public class PyTorchInferenceAdapter : IAiInferenceService
{
    private readonly HttpClient _httpClient;
    
    public PyTorchInferenceAdapter(HttpClient httpClient)
    {
        _httpClient = httpClient;
    }

    public async Task<AiReport> DetectAnomaliesAsync(Stream meshData)
    {
        // Detalles sucios de implementación: serialización, multipart form, etc.
        // La capa de aplicación es totalmente ajena a esto.
        var content = new MultipartFormDataContent();
        content.Add(new StreamContent(meshData), "file", "model.glb");

        var response = await _httpClient.PostAsync("http://gpu-cluster:8000/predict", content);
        response.EnsureSuccessStatusCode();

        var result = await response.Content.ReadFromJsonAsync<PyTorchResponseDto>();
        
        // Mapeo del DTO de infraestructura al objeto de contrato de Application
        return new AiReport(
            HasCriticalErrors: result.ConfidenceScore < 0.85,
            Summary: result.Findings
        );
    }
}

Tangible Benefits for Your Business

Adopting this architecture is not just an academic exercise; it has a direct impact on P&L (Profit and Loss) and your team's iteration speed.

1. Maintainability and Change Tolerance (Vendor Agnostic): Did the 3D inference provider raise prices by 300%? Switching to an internal open-source model means writing a new AiInferenceAdapter. You don't touch a single line of the Use Cases or the Domain. The regression risk is almost zero.
2. Extreme Testability: By depending on interfaces, you can mock IAiInferenceService in your Unit Tests. You can run thousands of tests validating your business rules in milliseconds, without needing to spin up heavy Docker containers with GPUs.
3. Parallel Scalability: With dependencies clearly separated, you can scale the infrastructure layer (for example, deploying multiple replicas of the AI worker or AI agent systems in C#) independently of the presentation API. ML engineers can work on the adapters while backend engineers improve the core business logic without stepping on each other's toes.
4. Security and Preservation: By establishing exhaustive domain validations, we inherently distrust user input and prevent corrupted geometries from poisoning our storage or overwhelming expensive processing, a critical concept in the backend architecture for generative AI.

Conclusion

At the intersection of traditional software engineering and modern 3D generative artificial intelligence systems, architecture is your only defense against chaos. Clean Architecture provides a clear map for integrating complex and unstable tools (like AI engines) into enterprise systems that require deterministic execution guarantees.

Don't let AI 'hype' destroy the quality of your codebase. Design strict contracts, protect your business domain, and leave infrastructure to the boundaries of your system.