5 great points why you use event source solutions?

The Event Sourcing Pattern

Joe has a habit whenever he did some transaction by his Debit card he used to write them in his Personal Diary so he can track his transactions. Joe is not a technology savvy and not able to check account statements online.

At the month end, his bank SMS him his current balance but he immediately notices a discrepancy between current savings what bank shows and as per his calculation based on the Diary. He immediately calls Bank helpline and arguing about the discrepancy. Then the bank sends him an Account statement with all transactions recorded.

When he is trying to match transaction records with his diary he understood one transaction not in the Diary as that day he was so sick, he thought it to write it next day but somehow forgot.

But the question is what we can extract from this story?

If we look minutely we discover one fact that Bank always stores all the events/transactions happens on the Account. Like Account creation, credit, debit etc. and the current balance is nothing but the outcome of those transactions. So what I meant to say is that account balance is not a fixed column in a database rather than it is a derivative/outcome of the transactions/events what were applied on the Account.We called it Event Sourcing.

Now think what we generally do in software if we credit or debit any amount we just add or subtract that amount from current balance and update the account with new balance right.

So we have the current state but lost the information how that state is achieved some system uses Audit trail still it is not fully deterministic. So anytime anyone challenges the system this is not the desired system state we don’t have any solid proof other than pleaded to them that system can not be wrong. But if you maintain that history or cause of the state changed like Bank then you just give them the History and asking to check -- a solid way to store proofs.

This is a very common story may anyone of us gone through the same and then look the Account statement for doubt clearing.

Technically what is Even Sourcing?

Event Sourcing is a technique by that we store all the changes of application state as a sequence of events. we can rebuild the state anytime from those events, also can query on the events to construct the desired state.

So the two key benefits are

1.we store all the events in a sequence which enables huge opportunities.

2.The state is the derivative of events so we don’t have to maintain state in the database rather we can programmatically derive state based on the event.

Now this opens a new direction that we don’t have to persist state rather we can derive state and it bring many advantages I will talk about 5 such advantages.

1. State Rebuild :  As we stores every event applies on an application object, we can create a blank /initial application object and apply every event in the same sequence it applied will bring the same state, so anywhere any point of time we can rebuild a state from events. So systems must have a mechanism to apply event, Then you can rebuild a state if the state is blown up for some reason. One may argue if your application state derives from millions of events applied on it, so computing all events may take time and also storing all events need a big storage area. but the fact is nowadays memory are really cheap also we can have TB of in memory space so computation is also faster, alternatively, we can store snapshot i.e milestone of the state and apply event and rebuild state from latest snapshot.

2.  Temporal Query : Event sourcing is perfect for Auditors. Business analysis team always want to see the past state so they can compare the growth or loss or any valuable statistical data so they need the flexibility to query the system in all possible way to collect statistical data. So If system has a feature to build the past state by passing parameters then analyst team will be delighted and the System which maintains all the state they can easily rebuild /compute the state by the parameters provide by the analyst team say analyst want to see the Account details for 10th December 2016, by event sourcing we can fetch all events till 10 the December and apply them in sequence to build the state and return the result to analysts -- easy job isn’t it.

Add caption

3. Comparing State : Sometimes in a complex system, you need to know if events were applied in different ways what would be the outcome and how much deviation it cause from the current state say, A bank saving account interest rate is 8% previously it was 8.5. Now if the bank wants to know due to the decrease of the interest what is the actual amount bank benefits so they will replay events of 8.5 percents in all accounts and compare the state with current state to know the actual benefits although it is not very easy to implement but we can.

4. Debugging State : Suppose there is a bug in production system and we need to debug why the bug happens by event sourcing it is very easy like copy the Account in Dev environment then change the Log level to Debug and apply event one by one in the sequence and check the outcome is predicted or not ,if not then  found the Event and check how it applies to change the application state to found the defect.

5. Future Prediction :  In some Business domain it is important task to analysis what will be outcome if we take some business decision, if the outcome is successful they will take the decision,But in a naked eye it is impossible to predict the application state as different services are interlinked with each other and based on one event they can change, dependent services are subscribed to certain events when that event occurs they take action on basis of event value.  say A bank’s stock share worth is 8 INR but bank analysis team predict  within 1 month it will be increased to 12 INR and they have moreover 30K stocks are public so analysis team wants to know what will be the effects of the application state if stock worth is 12 INR so they will run some ad-hoc future events on top of current state  based on two criteria.

Taking per stock as 12 INR

Taking per stock as 8 INR

Then compare two application states to find out what are the effect of this stock value increase for each interlinked services.

Conclusion : Some systems are inherently Event sourced like Version control (GIT), Banking application, Order Tracking application etc. but we can implement the same in general system also.Using Event sourcing you can easily back and forth you application state by replaying events and state cloning into any environment is just a matter of time but the Irony is, This pattern not used broadly in industry.

Read more

Hello, Hexagonal Architecture

Hello Hexagonal Architecture

While developing a software we always craving for Architecture because we want our software adopts future changes easily.

So, Architecture stepped in for maintainability. Here maintainability mean how easily we can incorporate changes without disturbing old.

Every feature addition in a software comes with a Risk, Risk of breaking old,maintainability,rigidity,dependencies etc, There are many shades of risks

we called it Technical debt.

Technical debt has an inverse relationship of maintainability, using Architectural style we want to decrease the risk or I can say make it constant while adding new features.

We experienced that when we start writing code at that time it is easy to add features and gradually it becomes hard unless we do not use proper architecture for that software.

Hexagonal Architecture:

We will discuss Hexagonal Architecture here, in one word Hexagonal Architecture says.

Core business logic talks to other through a contract.

The core business logic means your software development logic should talk to others means Database or any JMS Queues or any Flat files or HTTP request or FTP , NOSQL etc through a contract or in Java language we can say interface.

The benefits of above type of design is whatever the input or output channels that boil down to the contract so every channel has to implement that contract/interface to talking with our software, So for our software perspective all are same as all implement the same contract so our software can deal with any types of input and output channel .

Benefits:

1, Easily incorporates any channel like Flat file,RDBMS, NoSQL, Http,Ftp,JMS etc.

2. Our software can be easily tested because it is easy to create a mock as just need to implement the contracts.

3. Adding new requirements means plugging it, or implementing the contracts.

4. Proper separation of concern.

5. Maintains IOC as Higher level and lower level talking through contract.

Sometimes we called Hexagonal architecture as Port and Adapter or Onion architecture.

As in this architecture, we have a port for each channel say for Database

The tasks we have to perform

To implement the contract to talk with our software.

As database API say JDBC is itself a contract or Hibernate is itself a framework so we need to create an adaptor GOF adapter pattern where we have to implement a strategy which converts JDBC related operation to our contract related operation.

Then plug this adaptor into our port to talk with this channel.

Outline of the design

Software Contract

package com.example.architecture.hexagonal;

public interface IPersists<T,TCOMMAND> {

   

   public void save(T t,TCOMMAND commandObject);    

   public void delete(T t,TCOMMAND commandObject);

   

}

This is the general contract for talking with our software, any output channel like File channel, RDBMS,NoSQL should implement that contract.

Here I take an example How it can talk to JPA entity which saves that data in Database.

DataBaseChannelAdapter.java

package com.example.architecture.hexagonal;

public class DataBaseChannelAdapter implements IPersists<EmployeeDomainObject,EmployeeCommand>{

   public void save(EmployeeDomainObject t, EmployeeCommand commandObject) {

     

       String underLyingJPAEntity = commandObject.getEntityClass();

       System.out.println("call save on " + underLyingJPAEntity);

     

   }

   public void delete(EmployeeDomainObject t, EmployeeCommand commandObject) {

       String underLyingJPAEntity = commandObject.getEntityClass();

       System.out.println("call delete on " + underLyingJPAEntity);

     

   }

}

As JPA Entity use some JPA related annotation so I did not include this JPA entity as part of our Domain, I use JPA framework as an Outside Channel of our software domain and DataBaseChannelAdapter takes our core domain Employee Object and takes a Command Object which tells Adapter to Which JPA entity to call and call the same.

EmployeeDomainObject

package com.example.architecture.hexagonal;

public class EmployeeDomainObject {

   

   public String name;

   public String address;

   public String getName() {

      return name;

   }

   public void setName(String name) {

      this.name = name;

   }

   public String getAddress() {

      return address;

   }

   public void setAddress(String address) {

      this.address = address;

   }

   @Override

   public String toString() {

      return "EmployeeDomainObject [name=" + name + ", address=" + address

              + "]";

   }

   

   

}

Our core Domain Employee Object it does not dependent on any Framework so I can plug any framework with it through Adapter like I can easily change DatabaseAdapter to FileAdepter to save our core domain object in File.

EmployeeCommand.java

package com.example.architecture.hexagonal;

public class EmployeeCommand{

   

   public String entityClass;

   

   

   public String getEntityClass() {

      return entityClass;

   }

   public void setEntityClass(String entityClass) {

      this.entityClass = entityClass;

   }

   @Override

   public String toString() {

      return "EmployeeCommand [entityClass=" + entityClass + "]";

   }

   

   

}

This Command object is nothing but help Adapter to convert Core Domain Object to Underlying Output channel (Database or File)

EmployeeDomainDao.java

package com.example.architecture.hexagonal;

public class EmployeeDomainDao<T,TCommand>{

   

   IPersists<T,TCommand> adapter;

   

   

   public void save(T t,TCommand commandObject)

   {

      adapter.save(t, commandObject);

   }

   

   public void delete(T t,TCommand commandObject)

   {

      adapter.delete(t, commandObject);

   }

   public IPersists<T, TCommand> getAdapter() {

      return adapter;

   }

   public void setAdapter(IPersists<T, TCommand> adapter) {

      this.adapter = adapter;

   }

   

   

   

}

This is our Core Domain Persist layer here I use the adapter as Strategy based on the Adapter it will call exact output channel and persist our Domain Object.

Now Time to Test our Software design

Main.java

package com.example.architecture.hexagonal;

public class Main {

   

   public static void main(String[] args) {

      EmployeeDomainDao<EmployeeDomainObject,EmployeeCommand> dao = new EmployeeDomainDao<EmployeeDomainObject,EmployeeCommand>();

      IPersists<EmployeeDomainObject,EmployeeCommand> adapter= new DataBaseChannelAdapter();

      dao.setAdapter(adapter);

      EmployeeDomainObject emp = new EmployeeDomainObject();

      emp.setName("Shamik Mitra");

      emp.setAddress("India,Kolkata");

     

      EmployeeCommand command = new EmployeeCommand();

      command.setEntityClass("com.employeemanagement.entity.EmployeeJpaEntity");

     

      dao.save(emp, command);

      dao.delete(emp, command);

   }

}

Output:

Object StateEmployeeDomainObject [name=Shamik Mitra, address=India,Kolkata]

call save on com.employeemanagement.entity.EmployeeJpaEntity

Object StateEmployeeDomainObject [name=Shamik Mitra, address=India,Kolkata]

call delete on com.employeemanagement.entity.EmployeeJpaEntity

Hexagonal Layers :

Picture courtesy Google

Application Domain: As I said earlier it is the software where all software related business logic, validation goes on, this is the inside module every outside module talks with it through contract.

Application/Mediation Layer:  Kind of services layer it adopts the Framework layer or ut’s outside layer and make necessary changes according to domain layer contract to talks with Domain layer or in the same way return back the result from Domain to Framework layer.

It sits between Framework and Domain layer.

Framework Layer: This layer as to input/output channel or we can say the outside world and use an adaptor to adapt the data and transform it according to our  software contract.

Read more