That is understandable, because both have something to do with valid and invalid choices. Still they work differently, and that difference becomes important as soon as a product becomes more complex. I myself started thinking mainly from rules and parametric CAD for a long time. That also feels very natural: if this happens, then do that. Since I have worked with constraint-based configuration, I look at it with more nuance. Not because constraints are always better, but because they solve a different kind of problem.

A domain says what is possible

A domain is the simplest level for me.

It simply says which values a parameter may take. That can be a range, such as a width between 600 and 2400 mm, or a limited set of choices such as AISI 304 and AISI 316. A domain therefore does not yet make a choice and does not yet impose logic. It only indicates what is in principle possible.

Configuration often starts there.

An expression calculates something

Not every relation in a product model is immediately a rule or a constraint.

Sometimes a value simply follows from other values. If the leg length equals the working height minus the thickness of the top, that is simply a calculation. I see that as an expression. Nothing has to be searched or decided; the value follows directly from the model.

That looks banal, but it helps keep a system readable. If you treat every simple derivation as a rule or constraint, you make the model heavier than needed.

A rule works in one direction

A classic rule is usually directional.

You start from a condition and then set a consequence. If the width is larger than 1800 mm, you add a centre support. If the fire class is EI60, the door leaf gets a certain thickness. That kind of logic is powerful and often also very understandable. I have worked with it a lot in parametric CAD and iLogic, and I still use it today where the relation clearly goes in one direction.

For engineering automation that is often perfect.

A constraint says what has to remain true

A constraint works differently.

It does not necessarily say what has to happen first or last, but locks a relation that has to stay valid. The total width must for example be the sum of left margin, door width and right margin. Or the required torque must sit below what the chosen motor can handle. Or a plate length may not exceed the maximum fold length.

At that moment you are less describing a procedure and more a state that always has to hold. That becomes especially interesting when different choices influence each other at the same time and the user does not go through the product in one fixed order.

Why this becomes important on complex products

On a simple product you often get very far with rules.

But take a highly configurable door. Then door type, construction, material, fire safety, locks and steel frame all influence each other. You can of course model that with if/then logic, but over time a network appears in which exceptions stack on exceptions and the order of execution becomes important.

Then it becomes harder to still see whether you are modelling the product, or just writing a script that happens to represent a product.

Constraint-based configuration tries to approach that differently. You describe the relations that have to stay valid, and let the system help find which combinations are still possible.

Constraints are not a miracle cure

That does not mean constraints are always the best solution.

Some things are simply directional and therefore clearer as a rule. Others follow directly from a calculation and belong as an expression. And if a parameter only has a limited number of possible values, a good domain is enough.

I therefore prefer to look at it like this:

  • a parameter describes something about the product;
  • a domain says which values are possible;
  • an expression calculates a direct derivation;
  • a rule locks a direction;
  • a constraint watches a relation that always has to hold.

That may look like a theoretical distinction, but in a larger model it helps a lot. It makes clearer faster why a certain value exists and which kind of logic works on it.

Rules for automation, constraints for mutual dependence

In CAD automation, rules are often very natural.

A model has a clear input, then dimensions are calculated, parts are switched on or off, and drawings are generated. That is usually a fairly predictable flow. There does not necessarily need to be a solver in between, and usually a simple deterministic model is then better than a smart model nobody still understands.

In CPQ that is different.

The user can first choose material, then size, then execution — or exactly in another order. One choice can limit the possible values of another parameter, and some options can influence each other at the same time. At that moment it becomes important that the product model does not fully depend on the order in which the interface asks questions.

That is also what I found interesting when I started working with Tacton. The model then feels less like a script and more like a coherent system.

The UI is not the product model

That is another important distinction.

A configurator may feel very linear on the outside. You can have a perfectly clear flow with first type, then dimensions, then material and then options. But that does not mean the underlying model also has to be linear. The interface is how you lead the user through the product. The product model behind it has to contain the real relations and limits.

That later also makes it much easier to use the same product knowledge in another interface, API or engineering tool.

My preference: combine

I therefore do not believe so much in one pure approach.

For me a combination works best: expressions where something is simply calculated, rules where the direction is logical, constraints where choices mutually limit each other, and domains to make clear what can exist at all. If a clear product structure also sits above that, the whole stays much more readable.

That may sound less spectacular than “everything constraint-based”, but it is more practical for me.

The goal is not to build the smartest solver.

The goal is that the product model is still understandable in five years.