Where's the business logic?


Radan Skorić

Story time

It was a fine day and Radan was thinking about how to make the day even better.
Radan: I'll go grab lunch.
A wild sales person appears.
Sales person: Hey, quick question. What exactly happens when I edit the company and change its business type to Enterprise, I remember you guys saying you tied some logic to that.
Radan: Hm, yeah, I'm not sure, give me a moment, I'll check in the code.
Radan (thinking): Let's see ... hm ... and these callbacks run when ... why is this done like this ... what idiot wrote this ... oh, me ...
Radan (20 minutes later): Here's a list of all side effects. I'm mostly sure that's it.
Radan leaves, questioning his life choices.

Business logic is usually the fastest changing code in the system

Business/Domain logic encodes the real world rules of your business domain.

Business logic that changes
the state of the system

MVC process

Applying to a job on a job board

  1. Check that applicant skills match job requirements
  2. Create a job application record
  3. Notify job owner about a new applicant

All in the models

  • Put all the business logic into models, as special methods
  • Controllers do nothing but invoke methods on the model
All logic in the model

Pros

  • Only one place to look at for all the rules related to a certain model
  • Easy to add simple methods that are related to only one model

Cons

  • Hard to decide where to put code related to multiple models
  • Huge models
  • Hard to make it context dependent

All in the controllers

  • Controller actions contain all business logic checks and side-effects
  • Each controller action is responsible for a clear business action
All logic in the controller

Pros

  • Linear code, easy to read and understand
  • Easy to have it be context specific

Cons

  • Coupled with the delivery mechanism and HTTP response formatting
  • Hard to reuse business logic
  • Hard to check business action preconditions from view

Service objects

  • Introduce special objects to contain the business logic
  • Business actions are implemented as methods on the objects
  • Side effects and validations are explicitly stated in the methods
Service objects

Pros

  • Linear code, easy to read and understand
  • Easy to have it be context specific
  • Service objects can easily call other service objects

Cons

  • Need to introduce another type of entity into the system
  • Tends to cause somewhat big procedural style methods
  • Hard to check business action preconditions from views

Form / Business action objects

  • Each business action is a single class
  • Instances of the class are specific business actions
  • Expose methods needed to check validity and to execute the action
Business action objects

Pros

  • All logic related to a business action in one place
  • Business actions can mimic normal models
  • BAs can call other BAs
  • Easy to reuse same code (e.g. validations) in multiple contexts

Cons

  • Separate class for each business action
  • Logic can still become complex is same action behaves differently in different contexts
  • Long chains of business actions calling other business actions can become hard to follow

Data, Context, Interaction

  • Models are thin, only contain data, relationships and invariants
  • We introduce contexts that inject roles (extra behaviour) into models at runtime
  • The roles are responsible for implementation of interactions between models

Questions?

For reference, the approaches:

  • All in the models
  • All in the controllers
  • Service objects
  • Form / Business action objects
  • Data, Context, Interaction