Business/Behaviour Architectures

by Ludovic Lagouardette

Well divided responsibilities are generally a sign of a healthy codebase. MVC, stacks such as MEAN and LAMP, all the Go4 design pattern shenanigans... Those are just ways to this mean.

Another way to achieve separation is to separate business operations and behaviours.

What does a Business/Behaviour architecture?

A business/behaviour model combines low level programming of business objects with a high level interpreted or JIT-compiled scripting language in which behaviours are written.

Why use the Business/Behaviour architecture?

Two of the main benefits of this architecture are flexibility and power efficiency. This model is particularly powerful for IoT and for edge computing as well as for systems that may need to work isolated from the network or for which updates are hard to apply.

This pattern however may increase code size, particularly if bindings are heavy to write for your business logic to the chosen scripting language.

From a 3-tiers application to a Business/Behaviour architecture

Conversion to a Business/Behaviour architecture mainly consist in:

  • Adding an interpreter or alternative language to your project
  • Writing bindings glue code for how manipulation of business objects can happen
  • Rewriting the previous manipulations using the binding
  • Linking the user interaction to the scripts

A domain where this is really prevalent is video-game development: This allow to separate the game (behaviours) from the business logic (the engine, 3D, effects...) in a way that allows game mechanics creative staff (level designers, artists, AI developers...) to have different concerns and a different codebase than game engine creators.

An example

In this example, we create a simple 3-tier web app in crystal. We then add a logic to carter to a specific "customer" in Crystal. We then add an interpreter to separate behaviour from functionality, adding a lot of flexibility in the app.