Top 30 Clean Architecture Interview Questions and Answers [2026]

TL;DR: Clean Architecture interviews test one rule: source code dependencies point inward, toward business rules. Expect questions on where use cases, repository interfaces, transactions and mapping live, and how to enforce the rule in a build. In 2026 that means tools such as ArchUnit 1.5, and knowing that AutoMapper and MediatR now need a paid license for larger companies.

Robert C. Martin's post "The Clean Architecture" is dated August 13, 2012, and its central rule has not changed since: nothing in an inner circle may know anything about an outer one. What has changed is how teams enforce it.

Architecture tests now fail the build when an entity imports a framework class, and the .NET templates most candidates learned from swapped out libraries after their licenses changed in 2025.

Core Principles

1. What is the Dependency Rule?

Source code dependencies can only point inward. In Martin's original post, nothing in an inner circle may name anything in an outer circle: no class, function or variable.

So an entity never imports a web framework, an ORM or a message client. Business rules can then be tested and changed without the database or the UI. Everything else in Clean Architecture follows from this one rule.

2. How can a use case save data if it cannot depend on the database?

Through dependency inversion. The use case layer defines an interface for what it needs. An outer layer implements it. At runtime the call goes outward, but the source code dependency points inward.

// application layer (inner)
public interface OrderRepository {
  Order find(long id);
  void save(Order order);
}

public class PayOrder {
  private final OrderRepository orders;
  public PayOrder(OrderRepository orders) { this.orders = orders; }

  public void execute(long id) {
    Order order = orders.find(id);
    order.markPaid();          // the business rule lives in the entity
    orders.save(order);
  }
}

// adapters layer (outer)
public class JdbcOrderRepository implements OrderRepository { ... }

The interface belongs to the layer that uses it, not the one that implements it. That ownership is the whole trick.

3. What are the four circles, and must you have exactly four?

From the inside out: Entities (business rules for the whole enterprise), Use Cases (rules for this application), Interface Adapters (controllers, presenters, gateways) and Frameworks and Drivers (web, database, devices).

You need not have exactly four. Martin's post says the circles are schematic and you may need more. Only the Dependency Rule always applies. A candidate who insists on four folders is repeating the diagram, not the idea.

4. How is this different from a classic layered architecture?

In a classic stack, presentation depends on domain and domain depends on data access. The business layer therefore imports the persistence layer.

Clean Architecture turns the last arrow around: data access depends on interfaces the domain or application layer owns.

The layers can look alike on disk. The difference is which way the imports point. Fowler's note on layering covers the classic version.

5. How do Clean, Hexagonal and Onion architecture relate?

They are three names for one idea, published in this order:

• Hexagonal, or Ports and Adapters: Alistair Cockburn's 2005 article. The app talks to the outside through ports, and adapters plug into them.
• Onion: Jeffrey Palermo's 2008 series. Adds named rings inside the core, with the domain model at the center.
• Clean: Martin, 2012. Folds both in and names the Dependency Rule.

All three keep I/O at the edge. The differences are mostly vocabulary, so a good answer maps the terms instead of ranking them.

6. What is Screaming Architecture?

Martin's 2011 post argues that the top-level structure should say what the system does, such as a health care system, not which framework it uses. A reader should see billing and appointments before they see controllers and models.

In practice this pushes toward grouping code by feature, then by layer inside each feature.

Layers and Boundaries

7. What belongs in an entity? Is it the same as an ORM entity?

An entity holds the business data and the rules that must always hold for it, such as "an order cannot be paid twice." It has no framework imports.

It is not the same as an ORM entity by default. An ORM class carries mapping annotations and must fit the ORM's rules, such as no-argument constructors. Strict teams keep a separate persistence model and map between the two.

Pragmatic teams accept a few annotations on the entity to save that work. Either choice is fine if the candidate can say what it costs.

8. What does a use case do?

A use case, or interactor, runs one application action, such as PayOrder or RegisterUser. It loads entities through interfaces, calls their methods, saves the result and returns output data.

It holds the flow, not the core rules. If a use case checks that an order is unpaid by reading a flag, that check probably belongs in Order.markPaid().

9. What is the difference between a controller and a presenter?

A controller turns input, such as an HTTP request, into a plain request model and calls the use case. A presenter turns the use case's output into a view model the UI can show: formatted dates, labels, flags for what to display.

In most web APIs the presenter is a small mapper to a response DTO, and many teams fold it into the controller. That is fine as long as the use case never formats data for one UI.

10. What data should cross a boundary?

Simple data structures owned by the inner layer: request and response models, often records. Never a framework object such as an HTTP request, and usually not the entity itself.

Passing an ORM entity out to a controller ties the API to the schema. Passing an HTTP request into a use case ties business code to the web framework. Both break the Dependency Rule in a way that is easy to miss in review.

11. Where do repository interfaces live?

In an inner layer, next to the code that uses them. Usually that is the application (use case) layer, sometimes the domain layer when domain services need them. The implementation lives in the outer adapters layer.

A tell in code review: an interface named IOrderRepository in the infrastructure project, next to its only implementation. The dependency then points the wrong way, and the interface adds nothing.

12. Where do transactions start and end?

At the use case boundary. One use case call is one unit of work: it commits if the use case succeeds and rolls back if it throws.

The use case should not import the transaction API. Common ways to keep it out: a decorator around the use case, a pipeline behavior in a mediator, or a framework annotation on the outer class that calls it.

A unit-of-work interface in the application layer is another option.

13. Where does validation go?

In two places, for two kinds of rules. Format checks, such as "email is required" or "quantity is a number," go at the edge, in the controller or request model.

Business rules, such as "quantity cannot exceed stock," go in entities or use cases.

Putting business rules only in the API layer means a second entry point, such as a message consumer, skips them.

14. Where does authorization belong?

Coarse checks, such as "must be logged in" or "must have the admin role," can sit at the edge. Rules about data, such as "a user can only cancel their own order," belong in the use case, which receives the caller's identity as input.

That keeps the rule in force for every entry point, and makes it testable without a web server.

Implementation

15. How would you lay out the projects or modules?

Use one build unit per layer so the compiler enforces direction. In .NET that is often four projects: Domain, Application, Infrastructure and Web. Application references only Domain. In Java, the same shape works as Gradle or Maven modules.

Only the outermost project, the composition root, references everything. It wires implementations to interfaces at startup.

16. Should you package by layer or by feature?

Increasingly by feature. Jimmy Bogard's vertical slice architecture (2018) groups each request's code together and lets each slice choose how much structure it needs.

The two are compatible. A common layout is feature folders on the outside and the Dependency Rule inside each feature.

The mistake is folders like Services and Repositories holding 200 files each, where changing one feature touches five folders.

17. How do you enforce the Dependency Rule automatically?

With architecture tests that run in the normal test suite. In Java, ArchUnit:

@AnalyzeClasses(packages = "com.acme")
class DependencyRuleTest {
  @ArchTest
  static final ArchRule domainIsIndependent = noClasses()
      .that().resideInAPackage("..domain..")
      .should().dependOnClassesThat()
      .resideInAnyPackage("..application..", "..adapters..", "org.springframework..");
}

We ran this rule with ArchUnit 1.5.1 against a sample where Order.markPaid() called an adapter class.

It failed with the exact line: Method <com.acme.domain.Order.markPaid()> calls method <com.acme.adapters.AuditLog.write(...)> in (Order.java:7).

ArchUnit also has a ready-made onionArchitecture() rule. It fails on an empty layer unless you call withOptionalLayers(true). In .NET, ArchUnitNET or separate projects do the same job.

18. How do you map between layers without drowning in mappers?

Map only where a boundary protects something. A read-only screen can query straight into a response record and skip the entity. A write path usually needs request model to entity, and entity to response.

Hand-written mapping methods are plain, fast and easy to debug. Compile-time generators such as Mapperly in .NET or MapStruct in Java remove the typing without runtime reflection.

Runtime mappers hide mistakes until a field is silently null in production.

19. Do reads need to go through use cases and entities?

Often not. Loading full entities to build a list screen wastes queries and memory. Many teams let read requests go to a query service that returns DTOs straight from the database. Writes keep the full path through entities.

That split is the core of CQRS. Our CQRS interview guide covers where it helps and where it adds cost.

20. How do you handle logging, metrics and transactions without cluttering use cases?

Wrap use cases instead of editing them. A decorator, a pipeline behavior in a mediator library, or an aspect adds logging, timing, retries and transactions around every use case. The use case keeps only business steps.

Business events are different. "Order paid" is part of the domain, so the entity or use case records it on purpose.

Testing and Trade-offs

21. How do you test each layer?

• Entities: plain unit tests, no mocks. The fastest and most numerous.
• Use cases: unit tests with in-memory fakes of the repository interfaces. Fakes beat mocks here, because they test behavior, not calls.
• Adapters: integration tests against real infrastructure, such as a database in a container, to prove the SQL and mapping.
• Whole app: a few end-to-end tests through the real entry point.

If testing a use case needs a web server or a database, the Dependency Rule is broken somewhere.

22. When is Clean Architecture overkill?

When there is little business logic to protect. A CRUD admin tool, a thin API over a database, a prototype or a short-lived script gain little from four layers and pay for every mapper.

A strong answer names a signal for adding structure later, such as rules starting to repeat across controllers. Starting simple and adding boundaries when the logic grows is a valid plan.

23. What mistakes do teams make most with it?

• An interface for every class, including ones with one implementation that will never change.
• Entities with only getters and setters, and all rules in use cases. Fowler calls this the anemic domain model.
• Mappers that copy the same fields through four layers without protecting anything.
• Repository interfaces defined in the infrastructure project.
• A shared "Common" project that every layer depends on and that grows without limit.

24. How would you introduce it into an existing codebase?

One feature at a time. Pick an area with real business rules that changes often. Pull its rules into entities with unit tests. Put an interface in front of its data access. New code follows the rule, old code moves when it is touched.

Add an architecture test that covers only the migrated packages, then widen it. A big-bang restructure stalls feature work for months and usually gets abandoned.

25. How does Clean Architecture relate to Domain-Driven Design?

They answer different questions. Clean Architecture says which way dependencies point. DDD says how to model the business inside the core: aggregates, value objects, bounded contexts.

They fit together: DDD's aggregates sit in the entities circle, and its repositories are the interfaces from question 11. See our DDD interview guide for the modeling side.

26. Is the database really just a detail?

For the business rules, yes: they should not change when the database does. For the system as a whole, no. Transactions, locking, indexes and query shape decide whether it works under load.

A senior answer holds both views. Keep the rules independent, but design persistence with care, and do not pretend a swap from PostgreSQL to a document store is free because the interfaces compile.

What Changed Recently

27. AutoMapper now needs a license. How would you map between layers?

AutoMapper 15, released July 2, 2025, requires a license key and moved from MIT to a dual commercial and open-source license. The free Community license covers companies under $5 million in annual revenue that have raised under $10 million.

Older versions keep their MIT license.

A good answer treats this as a design question, not only a cost one. Options: hand-written mapping, a source generator such as Mapperly, or fewer mapping layers. Many teams found they needed less mapping than they had.

28. What do the popular .NET Clean Architecture templates look like now?

Both main templates moved to .NET 10 in November 2025: Jason Taylor's v10.0.0 on November 11, and ardalis v11.0.0 on November 13.

The ardalis template's package list now uses Mediator.SourceGenerator, an MIT-licensed library that builds dispatch code at compile time, instead of MediatR. MediatR 13 moved to the same commercial model as AutoMapper.

A candidate who learned from these templates should know which mediator their team uses, and why.

29. What did ArchUnit 1.5 add?

The 1.5.0 release on August 4, 2026 added:

• An archunit-junit6 module for JUnit 6.
• Support for Java 27 class files.
• isSealed() and getPermittedSubclasses() on JavaClass, so rules can check sealed hierarchies.
• Dependencies from caught exception types, which earlier versions missed.

The last one matters for the Dependency Rule. A domain class that catches an ORM exception depends on the ORM, and now the tests see it. Version 1.5.1 followed on September 25, 2026.

30. Can Spring Modulith check a hexagonal or onion structure?

Yes, through jMolecules. When the jMolecules ArchUnit rules are on the classpath, Spring Modulith's verify() runs them too. Per the verification docs, you can ask for strict hexagonal checks:

var hexagonal = JMoleculesArchitectureRules.ensureHexagonal(VerificationDepth.STRICT);
var options = VerificationOptions.defaults().withAdditionalVerifications(hexagonal);
ApplicationModules.of(Application.class).verify(options);

Spring Modulith 2.0, released November 21, 2025, switched the automatic hexagonal check to lenient mode. Strict checking is now something you turn on, as above.

Signs of a Strong Answer

• They explain the Dependency Rule in terms of imports, and can point to where the interface lives.
• They say when not to use Clean Architecture, with a concrete example.
• They put business rules in entities and keep use cases thin.
• They enforce boundaries with a build tool or an architecture test, not a wiki page.
• They map only where a boundary protects something, and can say what each mapper buys.

Hiring Clean Architecture Developers

Second Talent matches companies with pre-vetted software architects and back-end engineers across Asia. They work in Java and .NET codebases built this way. See rates in our backend developer cost guide.

Tell us about the role and we send a shortlist within 24 hours. For related topics, see the microservices and Spring Boot guides.