Homiepedia
Menu
Theme

Reviewing an Architecture Choice for a Configuration Tool

A step-by-step way to review "we chose Clean Architecture for our configuration tool" when you do not know the tool yet. What to ask, what to look for, which alternatives to raise and how to word the verdict.

Researched
14 Oct 2026
Reading time
11 min
Sources
4
Review due
14 Oct 2029
TL;DR
  • Judge fit, not the style in the abstract: an architecture is correct only against a set of drivers.
  • Spend the first half of the call discovering drivers; identify which kind of configuration tool it is.
  • Ask them to walk one real use case through all layers — it reveals more than any diagram.
  • The most likely verdict is fit with conditions; the value of the review is in the conditions.
On this page 12 sections
  1. Reframe the question
  2. Before the call
  3. Call agenda (60 minutes)
  4. Identify the tool type first
  5. Question bank
  6. Probe their design
  7. Green and red flags
  8. Alternatives to raise
  9. Fit scorecard
  10. Verdict and wording
  11. Key questions in Czech
  12. After the call

Reframe the question

“Confirm that our chosen design pattern suits our configuration tool” hides three separate questions. Answer them separately:

Question What you need to know
1. Is the style a sensible fit? Domain complexity, integrations, lifetime, quality attributes, team. Use the scorecard below.
2. Is their version of it sound? Their layering, what sits in Domain, how boundaries are enforced, which template add-ons they adopted.
3. Is it sufficient? Does it address the hardest problems of a configuration tool — rule model, extensibility, versioning, device I/O? Usually only partly.

If the request calls it a “design pattern”, correct it once and lightly: it is an architectural style, so it must be justified by system-wide quality goals — not by a beginner article that lists only benefits.

Before the call

Ask for these up front

Call agenda (60 minutes)

Half the call is discovery. Judge their design only after you know the tool and its drivers.

  1. 00–05Goal and outputAgree what "confirm" means and what you will deliver. Warn that context questions come first.
  2. 05–20The toolWhat it configures, for whom, how it is delivered, what it connects to. Identify the archetype.
  3. 20–30DriversTop 3–5 quality attributes, constraints, team, lifetime. Make them rank, not just list.
  4. 30–45Their designWalk one real use case end-to-end through their layers.
  5. 45–55Risks and alternativesWhat did they consider? Raise the 1–2 alternatives matching their archetype.
  6. 55–60Next stepsOpen questions, follow-up material, date of the written verdict.
60 minutes. The blue and green blocks are discovery; the design walk-through only starts at minute 30.

Identify the tool type first

“Configuration tool” covers very different systems. Place theirs in one of these within 15 minutes; the rest of the review depends on it. Two questions do most of the sorting: how much real logic is there, and how much do its integrations change?

Where the five archetypes usually sit. Green: strong fit; amber: fits as a shell around something else (a rule engine, a model, a reconciliation loop); red: overkill.
Archetype Signals Hardest problem Clean Arch fit Also needs
Device / ECU parameterisation Desktop tool talking to hardware (CAN, CANopen, Modbus, UDS, serial); parameter sets; firmware versions Many device families and protocols; testing without hardware Strong Plugin model per device family; simulator adapters
Product configurator (CPQ) Variants, options, compatibility rules, pricing, BOM output; sales users Rule / constraint model; who maintains rules Shell only Rule or constraint engine; rules as data
Engineering model tool Metamodel, ARXML/XML import-export, code generation (AUTOSAR-like) Model semantics, metamodel versions, round-tripping Partial Model-driven design; pipes & filters for generation
System / infra configuration Declarative files, environments, GitOps, CLI Idempotency, diff and apply, drift Partial Declarative model + reconciliation loop
Settings / admin UI Forms over a database, little logic Mostly UX and access control Overkill Simple layered or vertical slices

Listen for regulated contexts too — automotive (ISO 26262, ASPICE), industrial (IEC 61508), medical (IEC 62304). Tool qualification, traceability and testability raise the value of a clean, testable core.

Question bank

You won’t ask all of these. Items marked must are the ones not to leave without.

A · The tool and its users
B · Business logic and rules
C · Integrations
D · Quality attributes
E · Team and organisation
F · The decision itself

Probe their design

If a design or code exists, ask them to walk one real use case end to end — ideally change a parameter → validate → save or deploy. Check these as they talk:

Design probe

Green and red flags

Green flags

  • Concrete drivers: device families, protocol changes, hardware-free testing, long lifetime.
  • The domain contains real rules, and they can point to them.
  • Ports exist where variation exists — transports, formats, storage.
  • A plan for enforcement: references or architecture tests.
  • Pragmatism: simple features may skip layers; partial boundaries where cheap.
  • A thought-through rule representation and extension model.

Red flags

  • "Best practice" is the only justification, or a beginner article the only source.
  • The tool is mostly forms over a database.
  • Nobody on the team has used the style, and the deadline is tight.
  • Full template adopted wholesale (CQRS, MediatR, mappers) with no requirement behind it.
  • The hard problems — rules, versioning, extensibility — are not addressed at all.
  • One or two developers with four-plus projects of ceremony.

Alternatives to raise

Pick the one or two that match the archetype. Present them as complements or simplifications, not as “you are wrong”.

If you hear… Suggest How to phrase it
“New device families or customer variants all the time” Plugin / microkernel on top of Clean “Clean protects the core; a plugin contract lets you add a family without a release.”
“Rules change often; experts maintain them” Rule engine, rules as data “The rules are the product — decide their representation first, then layer around it.”
“Lots of simple screens, a few complex flows” Vertical slices, Clean only where complex “Keep simple features simple; full layering only where there is logic to protect.”
“Small team, need to ship this year” Hexagonal-lite: core + ports, fewer projects, no CQRS “Keep the dependency rule, drop the ceremony.”
“Several sub-domains or teams” Modular monolith, Clean inside each module “Split by domain first, by layer second.”
“Import, transform, generate” Pipes & filters, model-driven “This is a compiler-shaped problem — structure it as stages.”
“We need full audit and undo” Event sourcing for the configuration aggregate “Consider it for configuration history only, not the whole system.”

Fit scorecard

A thinking aid, not a formula. Leave ? where you didn’t learn enough — those become follow-up questions.

Business-rule complexity (validation, dependencies, compatibility)
Number and volatility of integrations (devices, protocols, formats)
Expected lifetime and likely technology changes
Testability or certification demands
Team size or several teams in parallel
Team experience with Clean, Hexagonal or DDD
Share of the tool with real logic beyond forms over data
Schedule room for upfront structure
Not scored yet

Rate the drivers above. Anything left at “?” becomes a follow-up question.

How this is scored

Each answered driver scores 0–2 (High = 2). The share of the maximum for answered drivers decides the leaning: 75% and above “fits”, 45–74% “fits with conditions”, below 45% “reconsider”. Unknowns don’t count but are listed. It is a thinking aid, not a formula.

Verdict and wording

  1. ReconsiderCosts outweigh gains; a simpler structure meets the goals.
  2. Fit with conditionsThe usual outcome: keep the style, attach conditions.
  3. FitDrivers clearly favour it and their version is sound.

The marker follows the fit scorecard above once you rate at least one driver.
Verdict When Suggested wording
Fit Drivers clearly favour it and their version is sound. “Clean Architecture is an appropriate choice because of X, Y and Z. Record the decision in an ADR and enforce the dependency rule with architecture tests.”
Fit with conditions (most likely) The style fits, but the implementation needs simplifying or completing. “The style fits the drivers, provided that: (1) the rule model is designed explicitly, (2) the extension model for new device types is defined, (3) layering is reduced to what is needed, (4) the dependency rule is enforced in CI.”
Reconsider Simple tool, small team, short time — or the real problem lies elsewhere. “Full Clean Architecture adds more cost than value here. A simpler layered or vertical-slice structure that keeps logic independent of the UI meets the stated goals.”

Typical conditions to attach:

  • An ADR with drivers, options considered and consequences.
  • Dependency rule enforced by project references and an architecture test in CI.
  • Rule representation (code vs. data) and extension model defined explicitly.
  • Template add-ons without a requirement behind them dropped.
  • Simple features allowed to skip layers — written down, so it isn’t treated as a violation.
  • A simulator or fake adapter for every external system from day one.
  • A review after the first two or three features: files per feature, what landed in Domain.

Key questions in Czech

Czech English
Co přesně váš konfigurační nástroj dělá a kdo ho používá? What exactly does your configuration tool do and who uses it?
Které vlastnosti kvality jsou pro vás nejdůležitější – testovatelnost, rozšiřitelnost, výkon, bezpečnost? Which quality attributes matter most to you?
Kde má žít byznys logika – v kódu, nebo v datech (pravidla, šablony, schémata)? Should business logic live in code or in data?
Jak často přibývají nové typy zařízení nebo produktů a jak je budete přidávat? How often are new device or product types added, and how?
Jaké alternativy jste zvažovali a proč jste je zamítli? Which alternatives did you consider and why did you reject them?
Jak zajistíte, že závislosti budou směřovat jen dovnitř? How will you ensure dependencies only point inwards?
Můžete nám projít jeden konkrétní případ užití skrz všechny vrstvy? Can you walk us through one concrete use case across all layers?

After the call

A short written review (2–3 pages) is usually what such a request expects:

  1. Context and scope — what was reviewed, from which material, and its limits.
  2. Drivers — the ranked quality attributes and constraints as understood; ask them to confirm.
  3. Assessment — fit of the style, soundness of their version, gaps it doesn’t address.
  4. Verdict — fit / fit with conditions / reconsider.
  5. Recommendations — numbered, actionable, each tied to a driver.
  6. Open questions — everything still scored “?”.

Key takeaways

  1. Discover the drivers first; judge the style against them second.
  2. Identify which kind of configuration tool it is in the first 15 minutes; the answer depends on it.
  3. Ask for one real use case walked through all layers; it reveals more than any diagram.
  4. Expect fit with conditions; the value of the review is in the conditions you attach.

Sources

  1. The Clean Architecture · Robert C. MartinPrimaryblog.cleancoder.com
  2. Vertical Slice Architecture · Jimmy BogardPrimaryjimmybogard.com
  3. Domain layer · Android Developers — an example of optional layeringPrimarydeveloper.android.com
  4. Ready for changes with Hexagonal Architecture · Netflix TechBlogPrimarynetflixtechblog.com
TagsArchitecture reviewClean ArchitectureConfiguration toolsConsulting

Related

Field guide15 Oct 2026 · 6 min

Hexagonal Architecture (Ports & Adapters)

What Ports & Adapters is, how it differs from Clean and Onion, and how to apply it to a tool with many inputs and devices. For architects who want a testable core with less ceremony than full Clean Architecture.

Comparison15 Oct 2026 · 5 min

Which Architecture Style When?

A side-by-side comparison of layered, Clean, Hexagonal, Onion, Vertical Slice, Modular Monolith, Plugin and microservices, with criteria, ratings, scenarios and a decision procedure. For architects choosing or reviewing a structure.

Field guide15 Oct 2026 · 7 min

Plugin / Microkernel Architecture

What a plug-in (microkernel) architecture is, the design decisions behind contracts, loading, isolation and versioning, and how to apply it to a configuration tool with many device families. For architects designing or reviewing extensible tools.

↑ ↓ to moveEnter to openFull-text search by Pagefind