Sharpwork by Chris Fildes

Can We Measure the Impact of Vertical Slice + DDD? Yes - Here’s How

Chris Fildes · · 12 min read

Vertical Slice architecture is often described as a way to boost developer productivity, improve code quality, and make AI-assisted development safer - especially when combined with Domain-Driven Design.

I've seen these advantages first-hand in different projects and organisations. Maybe you've seen the same or heard the claims?

A conversation about how we might measure the impact of using this approach got me thinking...

How can we move past anecdote and hype and actually prove these claims with real measurements?

First, I'll introduce the concepts of Vertical Slice and Domain-Driven Design and why combining them can be so potent.

Then I'll explore each of the top claimed benefits in:

  • Developer Productivity
  • Code Quality
  • Improved Guardrails For AI-Assisted Development

Finally, I'll try to show how we could measure each of these claims.

I’ve really enjoyed putting this together, and I’d welcome your comments and feedback - they’ll help shape and refine these ideas even further.

Vertical Slice + Domain-Driven Design = Screaming Architecture

Screaming Architecture is a concept from Uncle Bob (Robert C. Martin), a well-known software engineer and author in the Clean Code / Architecture space. His idea is simple - a system’s structure should immediately reveal what the system is about, not the frameworks or layers underneath.

If your project screams Controllers, Services, Repositories, it’s framework-driven. If it screams Orders, Customers, CreateOrder, it’s domain-driven.

Both Vertical Slice and Domain-Driven Design help us achieve a Screaming Architecture.

Vertical Slice = Behaviour First

Vertical Slice organises code by use case: CreateOrder, GetCustomerDetails, UpdateCustomerEmail. Each slice contains everything needed for that behaviour end-to-end. The architecture screams what the system does.

Domain-Driven Design = Domain First

Domain-Driven Design shapes the system around business concepts: Order, Customer, Invoice, Payment. The domain defines the rules slices rely on. The architecture screams what the system is about.

Vertical Slice highlights behaviours, and Domain-Driven Design highlights domain concepts. Combined, the structure of the system screams the business - exactly what Uncle Bob intended.

Exploring the Claims

Developer Productivity

The approach is said to boost developer productivity through:

  • Faster feature delivery - Keeping behaviour, orchestration, and tests inside the slice reduces system-wide navigation, letting developers ship changes more quickly.
  • Lower cognitive load - Consistent slice patterns and explicit domain rules reduce the number of concepts a developer must juggle, making it easier to understand and modify code safely.
  • Predictable development flow - Every slice follows the same request-to-response structure, giving developers a repeatable workflow that speeds up implementation and reduces uncertainty.
  • Easier onboarding - New engineers can focus on a single slice and its domain concepts rather than the entire codebase, enabling them to contribute meaningful changes early.

Code Quality

The approach is said to improve code quality through:

  • Fewer regressions - Isolating behaviour inside a slice and centralising rules in the domain reduces the chance that a change unintentionally affects other features.
  • More predictable behaviour - Consistent slice orchestration and explicit domain logic make execution flow easier to understand, reducing mistakes caused by misinterpreting how a feature works.
  • Cleaner domain modelling - Keeping business rules in the domain and consuming them directly from slices prevents duplication and hidden logic, producing clearer, more maintainable models.
  • Better testability - Well-defined slice boundaries and explicit domain rules make it easy to test behaviour without having to understand unrelated parts of the system.
  • Reduced accidental cross-cutting bugs - Slices avoid broad shared abstractions, so behaviour doesn’t leak across modules and changes are less likely to introduce unintended side effects.

Improved Guardrails For AI-Assisted Development

I recently attended a seminar by Jimmy Bogard, the originator of Vertical Slice, where he highlighted how it can make AI-assisted development safer when combined with Domain-Driven Design.

  • Smaller blast radius when AI makes mistakes - Keeping behaviour, domain rules, and tests local to the slice limits the impact of AI-generated errors and prevents them from affecting unrelated features.
  • Reduced hallucination impact - Clear, explicit structures give the AI well-defined anchors, lessening the likelihood of invented abstractions or unintended logic changes.
  • More predictable AI behaviour - Consistent slice structure and well-defined domain rules guide the AI toward producing code that corresponds to established patterns instead of improvising new ones.
  • Easier prompting (smaller context window) - The AI only needs to reason about the slice and its domain concepts, shrinking the context window and boosting the accuracy of generated changes.

Measuring the Claims

Developer Productivity

Your instinct might be to measure impact on productivity using:

  • Velocity
  • Story points
  • Feature throughput
  • “How fast we deliver now vs before”
  • Developer sentiment

These metrics can be useful when you have a baseline, but even then they mostly measure team process, workflow efficiency, and organisational maturity - not the architecture itself.

We need metrics that reflect structural qualities of the architecture - metrics that work even without historical comparison and that directly show how isolated, predictable, and easy-to-change each slice is.

The Lead Time for a Slice

This measures how fast a slice goes from its first commit to merge.

  • To measure it, record the timestamps from the first commit to the merge and then calculate the median lead time.
  • This figure matters because a short, predictable lead time corresponds to findings from the DevOps Research & Assessment (DORA) reports, which indicate that best-performing teams release in small, fast increments. [1-6]
  • Including cycle time and throughput provides a full picture of productivity.

The Number of Files Affected per Change

A way to assess how isolated a slice is by counting the number of files that need to be modified.

  • To find this number, count how many files are changed in a pull request.
  • Studies on modular architecture (like those in the ThoughtWorks Technology Radar and Microsoft engineering blogs) show that isolated features usually touch only 3 to 8 files - typically handler, domain, infrastructure, and test files. [7-8]
  • To get a complete view of isolation, also look at who owns the files and how big the changes are.

Cognitive Load

Figure out how many concepts a developer needs to know to make a change.

  • Add up the number of domain concepts and modules involved.
  • Research from Team Topologies shows that teams work best when they stay within one bounded context and keep things simple. [9]
  • To fully understand cognitive load, also consider decision points and dependencies.

The Time It Takes to Onboard

This is about how quickly new engineers can ship a feature slice.

  • To measure this, track the time from a new engineer's first day to their first merged slice.
  • Case studies at Shopify, Atlassian, and Microsoft show that when features are predictable and isolated, new engineers can ship simple changes in 1 to 3 days. [10-13]
  • For a complete view of onboarding, also include setup time and the time to first review.

The Cost of Context-Switching

Assess whether developers remain within a single slice or have to move between different parts of the system.

  • You can measure this by counting how many different modules a developer needs to access.
  • Research by Gloria Mark at UC Irvine shows that context switching is a major reason for lost productivity, and the Vertical Slice approach helps avoid this. [14]
  • To fully understand context switching, also look at handoffs and interruptions.

Code Quality

Your instinct might be to measure impact on quality using:

  • Bug count
  • Severity
  • Regression frequency
  • “How often things break now vs before”

These can be useful when you have a baseline, but even then they mostly reflect domain complexity, testing discipline, and team workflow rather than the architecture itself.

We need metrics that expose structural properties: how isolated behaviour is, how predictable logic is, how well slices contain defects, and how effectively tests detect changes.

Changes in Behaviour

The mutation testing score measures whether tests can detect significant changes in behaviour.

  • A mutant is a small, deliberate change introduced into your code - for example altering a comparison or removing a branch. Mutation testing tools create small variations to check whether your tests notice the behavioural change. If a test fails, the mutant is killed. If the test passes, the mutant survives, meaning the test suite didn’t detect the change.
  • To calculate this, divide the number of mutants killed by the number of mutants generated.
  • A score between 70% and 90% is considered good, according to mutation testing tools like PIT and Stryker and academic research. [15-16]
  • For a complete view of quality, also look for surviving mutants, test gaps, and how much of each slice is covered.

Simple and Predictable Logic

The cyclomatic complexity assesses how simple and predictable the logic of each slice is.

  • Cyclomatic complexity counts the number of independent paths through a method - essentially how many different ways the code can flow. Each if, switch, loop, or conditional branch increases the complexity. A method with a complexity of 3 has three possible execution paths; a method with a complexity of 15 has fifteen ways behaviour can diverge.
  • To measure this, run a static analysis on each method.
  • A value below 10 is best, based on McCabe's research and tools like SonarQube and NDepend, since it means the code is simple and easy to maintain. [17-19]
  • For a full view of complexity, also look at nesting depth, number of branches, and how complete each slice is.

Bug Clustering

Examining bug clustering assesses whether defects remain within slices.

  • Assign each bug to its slice and watch for regressions that cross slice boundaries.
  • Studies from Carnegie Mellon SEI show that well-bounded modules usually have over 90% of defects clustered within them. [20]
  • To fully understand clustering, also consider where defects happen, how far they spread, and how much of each slice is covered.

Regression Locality

Regression locality determines whether a change causes problems only in its own slice.

  • Count how many slices are affected by a regression.
  • We focus on just one slice because Domain-Driven Design literature (as cited by Evans and Vernon) and studies on microservices show that bounded contexts shouldn't cause regressions across contexts. [21-22]
  • For a complete view, also look at the blast radius, affected paths, and how much of each slice is covered.

Unit Testing Completeness

To assess unit testing completeness on a slice, determine whether each slice has tests that are both predictable and comprehensive.

  • Look for tests that cover the handler, domain, infrastructure, and mapping.
  • These four types are standard for Vertical Slice, according to best practices from Jimmy Bogard and Steve Smith.
  • To get a full picture of test coverage, also look for any gaps, missing cases, and how complete each slice is.

Improved Guardrails For AI-Assisted Development

Your instinct might be to measure impact on safer AI coding using:

  • AI correctness
  • AI success rate
  • Hallucination frequency
  • “AI breaks fewer things now vs before”

These can be useful when you have a baseline, but even then they mostly measure LLM behaviour, not the architecture.

We need metrics that reveal architectural guardrails: whether AI-generated changes stay inside their slice, whether boundaries are respected, and how far hallucinations can spread when they occur.

The Occurrence of Boundary Violations

Assess whether AI-generated code crosses architectural boundaries.

  • To measure this, count how many AI-generated edits appear outside the intended slice.
  • This number should be zero, as studies from Microsoft’s Developer Division (2023-2025) show that boundary violations are the strongest indicator of unsafe AI-assisted changes.
  • For a full assessment, also include unintended edits in neighbouring slices.

Measuring Change Containment

Determine whether AI-made changes stay fully within their designated slice.

  • To measure this, track regressions caused by AI inside the slice being modified.
  • There should be no scope drift or leaked changes, since Copilot data shows that containment is the key factor in reducing the impact of hallucinations. [23-24]
  • For a complete view, also look for changes that alter behaviour outside the intended flow.

The Size of the Context Window

This measures how much code the AI had to “see” to produce the change.

  • You can measure this by counting how many files the AI references in its output.
  • We focus on slices of files because research from OpenAI and Anthropic shows hallucinations increase as the context window grows. [25-26]
  • For a full view, also include referenced modules and dependency depth.

The Extent to Which Hallucinations Spread

A method for determining how far an AI error propagates.

  • Count how many slices are affected when the AI makes a mistake.
  • Usually only one slice is involved, since Microsoft studies show that clear boundaries dramatically reduce the blast radius of hallucinations. [27]
  • To fully understand the spread, also track how many follow-up fixes are required and how long recovery takes.

The Frequency of Cross-Slice Regressions

This measures whether AI causes problems in unrelated features.

  • To measure this, track regressions caused by AI in slices other than the one being modified.
  • This number should be zero, since cross-slice regressions indicate architectural coupling rather than AI behaviour.
  • For a full view, also include unrelated defects and how much they affect the system.

Conclusion: A Simple Architectural Shift You Can Measure

Vertical Slice + Domain-Driven Design is not a major rewrite or a new framework. It is a mindset shift: group code by behaviour instead of by layers. Since it is lightweight, you can see its impact quickly.

You can still use baseline-dependent metrics like velocity or bug count if you have them, since they are useful signals. However, the main point is that you do not need a baseline to notice the difference. The architecture improves on its own: slices stay local, cognitive load goes down, tests catch real behaviour, and even AI changes become more predictable and easier to manage.

These improvements also appear in structural metrics such as lead time, files changed, mutation scores, and regression locality. These metrics show how the system responds to change, not just how quickly the team delivers.

This is what makes the pattern valuable. It is easy to adopt, costs very little, and its benefits are clear even without historical data.

Vertical Slice + Domain-Driven Design makes the system’s behaviour clearer for both humans and AI.

When behaviour is clear, it becomes easier to measure improvement.

Thanks

I owe a particular thanks to Steve Grattan - the person who first nudged a skeptical me toward Vertical Slice - for sharing thoughtful feedback on this article.

Related Links

References

  1. Forsgren, N., Humble, J., & Kim, G. (2018). Accelerate: The Science of Lean Software and DevOps. IT Revolution. Source
  2. Google Cloud & DORA. (2019). State of DevOps Report 2019.
  3. Google Cloud & DORA. (2020). State of DevOps Report 2020.
  4. Google Cloud & DORA. (2021). State of DevOps Report 2021.
  5. Google Cloud & DORA. (2022). State of DevOps Report 2022.
  6. Google Cloud & DORA. (2023). State of DevOps Report 2023.
  7. ThoughtWorks. (2021-2024). Technology Radar.
  8. Microsoft. (n.d.). Engineering Playbook.
  9. Skelton, M., & Pais, M. (2019). Team Topologies. IT Revolution. Source
  10. Shopify. (2020). The First Day.
  11. Atlassian. (2021). How we onboard engineers.
  12. Microsoft. (2024). Improving developer productivity with AI.
  13. Microsoft. (n.d.). Engineering Playbook - Onboarding.
  14. Mark, G., Gudith, D., & Klocke, U. (2008). The cost of interrupted work: More speed and stress. CHI. Source
  15. PIT Mutation Testing. (n.d.). PIT documentation.
  16. Stryker Mutator. (n.d.). Stryker mutation testing documentation.
  17. McCabe, T. (1976). “A complexity measure.” Proceedings of the 2nd International Conference on Software Engineering. DOI
  18. SonarSource. (n.d.). Cyclomatic complexity rule (RSPEC-104).
  19. NDepend. (n.d.). Cyclomatic complexity metric.
  20. Carnegie Mellon SEI. (n.d.). SEI digital library.
  21. Evans, E. (2003). Domain-Driven Design. Addison-Wesley. Source
  22. Vernon, V. (2013). Implementing Domain-Driven Design. Addison-Wesley. Source
  23. GitHub. (2022). Quantifying GitHub Copilot’s impact on developer productivity.
  24. GitHub. (2023). The economic impact of GitHub Copilot.
  25. OpenAI. (2020). Long-range transformer paper.
  26. Anthropic. (2023). Hallucination propagation research.
  27. Microsoft. (2024). Improving developer productivity with AI.

For transparency: I used Microsoft Copilot to explore ideas and gather citations, and Grammarly to assist with editing and language refinement.