5

This seems an extreme question probably but I'm wondering anyhow:

Can all business logic be decomposed as a (declarative) state diagram on simple crud operations and conditionals?

Already a lot of lower-level domain logic can, and ofen is declaratively defined with ORM-mappings for instance, handling things like:

  • domain-model schema
  • validation
  • uniqueness constraints
  • ACL/ Role-based authorization, etc

Of course higher-level domain logic exists that often involves coordinating between multiple Domain Objects.

However, it seems ultimately:

  • This high level business logic really is just a workflow that can be modeled as a state-machine (or probably more extensive as a extended petrinet)
  • in which all branching is based on conditional logic on some state (i.e: domain object attributes)
  • the outcome would be a statechange, i.e: a change to domain object attributes (simple crud operations).

If this is the case, could all domain logic be declaratively defined, given a DSL that would support the above workflow, conditional, and CRUD constructs?

If you dismiss this braindump please be insightful while doing so :)

Geert-Jan
  • 673
  • 1
  • 5
  • 13

2 Answers2

6

Yes it can, but only in a practically useless sense.

The computation engines we usually use today are ultimately equivalent to Turing machines, which do exactly what you describe (in fact, they do less, because they have only linear-access memory to work with rather then random-access memory, but it can be proved that this makes no difference). But the state machines you would have to operate to encode even a simple application program are so disgustingly, terrifyingly huge that there is no question of actually using this model of computation in practice. It exists only as a theoretically possible mathematical entity of finite size, but on the large side of "finite".

The point of software engineering as a discipline is to find methods to program machines for more complex behaviour with smaller, more comprehensible programs. Reading and writing individual variables is easier than switching from one state to a neighbouring state that is almost the same except for one subposition in its composite alphabet. Writing loops is easier than leaving markers on an infinite tape and shuttling back and forth until a sentinel value occurs.

That is not to say that state machines don't have their place. When a problem domain can be naturally understood as transitions within a mentally manageable state space, they can be the most appropriate solution to encode some operation. However, these situations are rare enough that you can basically forget about them until you actually encounter one.

Kilian Foth
  • 107,706
  • 45
  • 295
  • 310
1

I've come across this question five years later, and it seems more relevant than ever. Functional programming and DSL's are hot right now, and both are examples of declarative behaviour.

Yes, I believe all business logic can be defined declaratively. Most business-specific behaviour is moving and displaying data. We already specify most data declaratively, as schemas in our databases. How the data moves can be specified via state diagrams or similar techniques, and permissions can be set by declarative authorizations of when and how data can move.

Further, perhaps all business-specific behaviour should be declarative, and only business-generic behaviour can be imperative. How many times have programmers implemented “put this address in a database, if it's well formed”? In a business declarative world, a programmer would create a schema and business rules / state diagram, permissions, etc. Then they would find off the shelf components to run the rules. If they needed some new tool, they would create a DSL for it, then implement it in a data generic way.

Ron Romero
  • 111
  • 3