Where Should a Business Rule Live: Controller, Service, or Domain Model?

In the article about the point where plain CRUD stops being enough I wrote about the point where simple create/update/delete operations stop being enough because rules start growing around the data.

The next practical question is almost immediate: where should those rules live?

At first, the easiest place is the controller. Later the controller becomes too large, so the rule moves into a service. But when the same rule is needed from HTTP, a command, a queue, or another use case, it becomes clear that the problem is not the entry point.

The rule belongs to the domain itself.

There is nothing unusual about this code. For a first version it may be completely sufficient.

The problem starts when I look at the conditions and realize that the controller is no longer making HTTP decisions.

It knows from which state the object may be activated and which data is required.

That is domain knowledge.

Input-shape validation does not automatically belong in the domain model.

Whether a field is a string, whether it exceeds a request limit, or whether the HTTP request is well formed belongs at the application boundary.

The controller may also shape an HTTP response, redirect, or return the required status code.

I do not move everything into the domain merely to make the controller look small.

This is already better than a large controller: the use case is isolated, easier to test, and easier to reuse.

But I ask one more question: what is this service actually doing?

If most of its code answers "is this object allowed to move into this state?", it is no longer only coordinating a use case.

The service now owns a rule that should remain the same regardless of how the action is triggered.

This is usually where my view of the code changes.

With one controller, the rule is easy to treat as part of that use case.

When a second entry point appears, copying conditions becomes dangerous, and relying on every caller to use one particular service becomes fragile.

If the rule describes valid state for the entity itself, the safest design is for the entity to make the rule difficult to bypass.

External code no longer knows the details of the rule.

It does not inspect status, check a list of fields, or assign the new value directly.

It asks the model to perform a meaningful action: activate().

If the state is invalid, the model rejects the action consistently from HTTP, a command, a queue, or a test.

If a rule must remain true after every valid operation, that is a strong sign that it belongs to the domain.

For example, "an active product must be complete" is not a rule of one form or one route.

It describes valid system state.

I try to place such rules as close as possible to the model whose state they protect.

The application service remains very useful.

It can open a transaction, load the aggregate, invoke the action, persist the result, and coordinate infrastructure concerns.

But it should not restate the conditions under which activate() is valid.

Its job is to coordinate the use case. The model protects the rule.

When I see a class named SomethingService, I no longer treat that as an answer to "where does the rule live?"

First I need to know what kind of service it is.

An application service coordinates a use case. A domain service may hold a domain operation when that rule does not naturally belong to one entity.

So "move it into a service" is not an architecture decision by itself.

I do not force every rule into an entity at any cost.

If a rule genuinely depends on several domain concepts and none naturally owns the decision, a domain service may be a cleaner choice.

It should still express a domain rule rather than HTTP, SQL, or queue mechanics.

For example, an administrator may be authorized to request activation while the product itself is not ready to activate.

The first check is about user permission. The second is about valid domain state.

I try not to collapse these different reasons for rejection into one large if.

The domain model is where I want the meaning of the rule to be visible.

But if part of an invariant can also be reinforced by a reliable technical constraint, I use that protection too.

I covered that second layer separately in an article about database constraints as the last line of defense.

The code explains the rule. The database can prevent clearly invalid state even if application code makes a mistake.

If I cannot decide where a rule belongs, the deeper problem is often unclear state ownership.

The question from the article about aggregates and consistency boundaries helps: which aggregate must guarantee this invariant?

Once state ownership is clear, rule placement usually becomes much easier.

If a rule can be naturally stated and tested without a route, request, or database, that is often a good sign.

The test reads like a business sentence: an incomplete product cannot be activated.

That is how I want important rules to look: separate from the mechanism that delivers the command into the system.

A few signals stand out to me:

• The same condition appears in several controllers.
• A service consists mostly of state checks for one entity.
• Code can assign status directly and bypass the method that contains the rule.
• A business-rule test needs an HTTP request even though the rule has nothing to do with HTTP.
• A service has a very generic name because it both coordinates the use case and decides domain rules.
• One large if mixes user permission, request shape, and valid model state.

While working on Center, I did not always recognize immediately that a check had become an invariant.

It often became obvious only when a second or third use case needed the same behavior.

This connects closely to the article about domain boundaries in a growing system: the domain gradually reveals not only its boundaries, but also the owners of its rules.

I therefore do not treat moving a rule from a service into the model as proof that the first version was wrong. It is often a normal result of learning more about the system.

I check:

• Is this rule about HTTP or about valid domain state?
• Must it behave the same from several entry points?
• Can direct model updates bypass the rule?
• Does one entity naturally own the decision?
• Is the service coordinating the use case or deciding what the business allows?
• Can the rule be tested directly without HTTP?
• Is it an invariant that must remain true after every valid operation?

For me, the answer to "Controller, Service, or Domain Model?" no longer starts with the class type.

I first identify what kind of rule it is.

If it is about request shape, it stays at the application boundary. If it coordinates a use case, it belongs in an application service. If it defines valid model state regardless of entry point, it belongs in the domain.

The more important the invariant, the closer it should live to the state it protects.