How to implement state machine pattern on aggregate root

Question

I am modeling an aggregate root, which has several actions that perform operations against other entities, as you'd expect. The aggregate, however, has a state, and several of these operations can only be performed when the aggregate is in a particular state.

I created an implementation of the state pattern, so that the aggregate would simply delegate the action to the state concrete object. However, now that I have implemented it, I found meself with the following concerns:

• There are operations that can be invoked in more than one state, thus I ended up repeating implementations.
• There are operations that generate domain events, so I had to pass the root's event collection so they can add the events properly.
• Some operations require access to the private members of the aggregate root, so I ended up either declaring them as internal (C#) or creating internal methods that modify the private members.

So now I'm wondering whether the implementation was worth it, or if the state object should only have CanPerformOperation1 properties, and let the aggregate root check this property and if false, throw an InvalidOperationException.

The following code is a summary of what I'm trying to attempt.

interface IState {
    void Register(DomainName domain, CustomerCode code);
    void Activate(ActivationManifest manifest);
    void Lock();
    void Unlock();
    void EnsureConsistency();
}
class NewState : IState {
    // can only call Register method, transitions to RegisteredState
}
class RegisteredState : IState {
    // can only call Activate method, transitions to ActiveState
}
class ActiveState : IState {
    // can call Lock or EnsureConsistency
    // Lock transitions to locked state
    // EnsureConsistency can transition to RestrictedState or ActiveState
}
class LockedState : IState {
    // can only call Unlock, transitions to ActiveState
}
class RestrictedState : IState {
    // can only call EnsureConsistency, which can transition
    // to ActiveState or RestrictedState
}

class Tenant {
    private IState _state = new NewState(this);
    private readonly UserAccountCollection _accounts;
    private readonly LicenseCollection _licenses;
    private readonly ApplicationCollection _applications;

    // had to make these internal accesors to be used by
    // EnsureConsistency in ActiveState and RestrictedState
    internal UserAccountCollection _accounts => _accounts;

    internal Application RegisterApplication(AppKey key, UserAccount admin){
        // this method is called by the RegisteredState.Activate method
        // so what's the point of delegating?
    }
    internal License RegisterLicense(LicenseKey key) {
        // this method is also called by the RegisteredState.Activate
        // method, just like the one above.
    }
    // etc
}

Now, this will only increase in complexity, as the customer requires me to add more methods that depend on state. So I was just wondering whether I should just add properties like CanRegisterApplication, CanRegisterLicense, etc., and then the states will only be acting as a flag switch.

What would be a proper way to implement what I'm trying to achieve? Or maybe I'm getting the state pattern wrong?

Answer 1

IMHO, "customer requires me to add more methods" is the exact reason why we need the state pattern in the first place. Without state pattern, it's likely that you need to repeat the switch or if/else in the new added methods.

From the implementation point view, abstract class is much easier than interface in state pattern.

Regarding your access modifier, you can make the each individual state as internal class of the client (Tenant class in your case, see nested types). By this way, you actually have better encapsulation as the external world doesn't need to know the actual state detail.

abstract class State {
    void Register(DomainName domain, CustomerCode code){};
    void Activate(ActivationManifest manifest){};
    void Lock(){};
    void Unlock(){};
    void EnsureConsistency(){};
}


class Tenant {
    class NewState : State {
        // can only call Register method, transitions to RegisteredState
    }
    class RegisteredState : State {
        // can only call Activate method, transitions to ActiveState
    }
    class ActiveState : State {
        // can call Lock or EnsureConsistency
        // Lock transitions to locked state
        // EnsureConsistency can transition to RestrictedState or ActiveState
    }
    class LockedState : State {
        // can only call Unlock, transitions to ActiveState
    }
    class RestrictedState : State {
        // can only call EnsureConsistency, which can transition
        // to ActiveState or RestrictedState
    }
    private State _state = new NewState(this);
    private readonly UserAccountCollection _accounts;
    private readonly LicenseCollection _licenses;
    private readonly ApplicationCollection _applications;

    // Should this go to abstract class State 
    private UserAccountCollection _accounts => _accounts;

    private Application RegisterApplication(AppKey key, UserAccount admin){
        // Should this go to abstract class State 
    }
    private License RegisterLicense(LicenseKey key) {
        // Should this go to abstract class State 
    }
    // etc
}

P.S: In java, people usually use enum to implement state pattern. However, .net doesn't allow polymorphism in enum.

Answer 2

I often encounter the same problem: I have some business-processes that require my aggregate to pass through several states, with some behavior specific to each state:

What I often do is split this aggregate with all its state classes into multiple separate classes, each one representing an aggregate in its specific state. For example, instead of one FinancialTransaction aggregate with states Registered, CheckedForFraud, Authorized, etc, I have RegisteredTransaction, CheckedForFraudTransaction, AuthorizedTransaction, etc.

Just to make it crystal clear, that's how it works. First, the command is issued by the client. It could be smth like Register transaction. Command gets validated, RegisteredTransaction is created and saved to db. Alongside Transaction is registered event is published with newly created transaction_id. It is consumed by some listener who wants to check whether this transaction is fraudulent. Say, it requires requesting some 3rd party service, and if it's ok, then CheckedForFraudTransaction is created. Under the hood it operates upon the same db table row (though it's not necessary) with the same transaction_id.

I like this approach, it doesn't make me to modify State's interface each time new behavior is added. Besides, each step is well isolated, could be mocked while integration testing, and the whole business-process is more clear.

Answer 3

Your implementation breaks the Open/closed principle because every new state implementation forces you to modify all the other implementations. I'm proposing an alternate approach, based on the Strategy pattern.

The idea is that your Tenant at any given moment is in a State and every State knows only the states that it may transition to. This frees your Tenant of the state transition algorithm. However, the Tenant is the one that commands the state transition, it is the one in control.

On the other hand, States should not know about the Tenant as they have only a single responsibility: to permit or reject transition to another State.

Following this pattern, the Tenant becomes very clean.

Here is an example of implementation (in PHP):

<?php

interface IState
{
    /**
     * @param IState $newState
     * @throws \Exception
     */
    public function tryTransition(IState $newState): void;
}

class NewState implements IState
{
    public function tryTransition(IState $newState): void
    {
        if (!($newState instanceof RegisteredState)) {
            throw new \Exception("Can only register");
        }
    }
}

class RegisteredState implements IState
{
    public function tryTransition(IState $newState): void
    {
        if (!($newState instanceof ActiveState)) {
            throw new \Exception("Can only activate");
        }
    }
}

class ActiveState implements IState
{
    public function tryTransition(IState $newState): void
    {
        if (!($newState instanceof RestrictedState) && !($newState instanceof ActiveState)) {
            throw new \Exception("Can only restrict or activate");
        }
    }
}

class LockedState implements IState
{
    public function tryTransition(IState $newState): void
    {
        if (!($newState instanceof ActiveState)) {
            throw new \Exception("Can only activate");
        }
    }
}

class RestrictedState implements IState
{
    public function tryTransition(IState $newState): void
    {
        if (!($newState instanceof RestrictedState) && !($newState instanceof ActiveState)) {
            throw new \Exception("Can only restrict or activate");
        }
    }
}

class Tenant
{
    /** @var IState */
    private $state = 0;

    /**
     * Other private data
     */
    private $_accounts;
    private $_licenses;
    private $_applications;

    public function __construct()
    {
        $this->state = new NewState();
    }

    public function RegisterApplication(AppKey $key, UserAccount $admin)
    {
        $this->tryTransitionOrThrowException(new RegisteredState());

        $this->_applications[] = new Application($key, $admin);
    }

    /**
     * @param IState $nextState
     * @throws Exception
     */
    private function tryTransitionOrThrowException(IState $nextState)
    {
        $this->state->tryTransition($nextState);
        $this->state = $nextState;
    }

    public function Activate(LicenseKey $key)
    {
        $this->tryTransitionOrThrowException(new ActiveState());

        $this->_licenses[] = new License($key);
    }

    public function Lock()
    {
        $this->tryTransitionOrThrowException(new LockedState());
    }

    public function UnLock()
    {
        $this->tryTransitionOrThrowException(new ActiveState());
    }
    // etc
}

Answer 4

What you are trying to build is State Machine and akka .Net Framework provides this functionality very neatly.

Read this link and patterns there will answer your questions