It is common for many Enterprise Applications to grow over time resulting in an accidental architecture. Accidental architecture is not entirely preventable. Deadlines, delivery schedule changes and other factors might force you to accrue technical debt. I am a firm believer of agile methodologies where you address the problem at hand and then come back and refactor when you have to address a new issue. I am definitely not advocating doing no design or architecture up front. As Uncle Bob Martin puts it, BDUF (Big Design Up Front) is bad but LDUF (Little Design Up Front) is good. Even when you follow these advices, it is entirely possible and normal to accrue Technical Debt and the solution is to embrace refactoring.

Once you do have a system with an accidental architecture in place, and you have to refactor it, part of that refactoring process will involve splitting your now monolithic application into individual services that can be scaled independently. Even if you have been modularizing your application well and have designed your application to use multiple services, your services could still be deployed in the same process or virtual machine.

As previously stated, Enterprise Applications typically have several moving parts. In addition to request processing, additional tasks your application is already performing may include Email Jobs, Reporting, Reconciliation jobs, Data processing tasks like risk analysis, even indexing and searching. A reconciliation task has a different Quality of Service requirement than regular request processing. If you are thinking of splitting your application, it makes sense to identify tasks that your application is already performing that have different QoS to the main functionality of your application and use that to split the tasks into independent services that live on your network.

Recently, at one of my clients, a reconciliation task built into the application was chocking up regular request processing in terms of memory. Splitting it into an independent service freed up the main server to provide much better response times. Pay attention to QoS requirements, identify services with different QoS requirements and use that to scale your architecture.

Since we have an interface for each and every domain object, the concrete Java classes are never exposed to the rest of the application except during the creation phase. Often, a factory (or abstract factory) pattern is also used to entirely abstract the Java classes away from the rest of the application.

Let us consider an example where we are modeling a CheckingAccount and SavingsAccount objects. We can define 3 interfaces that look like:
public interface Account {
// accessors...
}

public interface CheckingAccount extends Account {
// accessors...
}

Further, we define 3 Impl classes that implement each of these interfaces

public abstract class AccountImpl implements Account {
// accessor implementation
}

public class CheckingAccountImpl implements CheckingAccount {
// accessor implementation
}

Another way of implementing would be to use a java.lang.reflect.Proxy based dynamic Proxy to provide implementation to the domain interfaces. In this case, you will just code the interfaces and will rely on a factory to generate the implementations on the fly. While this method of implementation reduces the number of classes that you have to code, it suffers from the same problems that the above example does. Let us see why in the section below.

Just to clarify what I am making a case against, using interfaces/abstract classes to denote abstract concepts in the domain model is a perfectly valid use case. Example to that would be to define the account type from above as an interface or abstract class and define CheckingAccount and SavingAccount as concrete classes. But creating 2 parallel hierarchies one full of interfaces and one full of impl concrete classes each of which implement one interface is just redundant.

We typically use interfaces to achieve one or more of the following:
1. Provide multiple implementations if needed.
2. Abstract away creation from usage and use a factory.
3. Proxy and add functionality.
4. As poor man’s closures.
5. Expose a smaller subset of functionality outside a module.

Now let us consider the each of these

1. Provide multiple implementations if needed:
In any non trivial project, it is generally a good practice to keep any business rules and technical functionality away from domain objects and that means staying clear of patterns like the ActiveRecord. I would recommend using a clean domain model where the domain objects are pure POJOs that denote object relationships with other domain objects. If your domain objects are clean with no functionality, there is little point in creating multiple implementations of it.

2. Abstract away creation from usage and use a factory:
If you are designing an API or are building a large framework for your application, sometimes it does make sense to restrict the number of objects created for various reasons. I am usually not a fan of Object Pools but there are use cases where it may make sense. Even in this case, interfaces are not absolutely necessary for the domain objects as the number of object instances can be controlled by using a static factory method. The new JSR 310 – Date and Time API uses this approach. For example, take a look at the LocalDate class (pre-release at the time of this writing, so this link may expire) it does not expose constructors but exposes a few static factory methods to create objects.

3. Proxy and add functionality:
One advantage that interfaces provide is the ability to easily proxy the implementation and add functionality. This is useful if you have to implement hibernate style lazy loading. Even for this, there is little point creating a parallel interface hierarchy as cglib based proxies can easily handle this case. And, this is what hibernate does as well. Hibernate does not force you to create a parallel interface hierarchy for your domain objects.

4. As poor man’s closures:
Another reason why we typically use interfaces is as a poor man’s closures . We pass an interface as a callback so the caller can invoke our methods. This doesn’t even apply in our case as we tend not to implement any functionality inside of our domain objects.

5. Expose a smaller subset of functionality outside a module:
Interfaces also allow you to expose a smaller functionality than that is implemented by the underlying class. I have come across domain models that expose just the getters in their interfaces and implement setters in the concrete implementations. This in theory provides read only access to the API users. This might be dangerous at times because from the client’s perspective, the domain object is immutable but from the API’s side it is not. I’d suggest using immutable domain objects instead of faking immutability.

In APIs that deal with a rich domain model, it might be necessary to support different versions for different clients. The parallel interface layer for the domain model doesn’t really help us here. If we really need to support multiple versions with type safety, we will end up creating multiple domain models one for each version.

I have had to work on a couple of projects with domain objects that already had a domain model designed using the parallel interface hierarchy pattern, and in each of them the pattern offered no additional benefits and was a pain to maintain in the long term which eventually led to refactoring. I hope I made a solid enough case against the pattern. If you had different experiences with it and would like to add, please feel free to do so in the comments.

First, preparing Cassandra

First, download a copy of Cassandra and unzip it in the location of your choice, I’ll refer to this location as $CASSANDRA_HOME. We’re going to make a minor change to the $CASSANDRA_HOME/conf/storage-conf.xml file in order to create up a custom Keyspace for this example called “ExampleKeyspace”. In between the <Keyspaces/> node, insert the following code fragment:

Now that we finished defining the Keyspace and the ColumnFamily we’re going to use, let’s validate that the configuration file by starting Cassandra. In order to start Cassandra, run the following script $CASSANDRA_HOME/bin/cassandra You’ll know when Cassandra is a happy lady if you see “Binding thrift service to localhost/127.0.0.1:9160“ in the console. If you see “Bad configuration; unable to start server“, then the storage-conf.xml isn’t correct, please verify it.

How to verify that the storage-conf.xml changes were accepted

There are a few ways to verify that the configuration change we’ve made has taken place. If you’re a command-line person, execute the $CASSANDR_HOME/bin/cassandra-cli which will start the Cassandra command-line interface. Now that the shell is running, let’s connect to our instance that’s running by executing the following command within the cassandra-cli shell

connect localhost/9160

We’re using the default port since that remains untouched by us. Now that we’re connected, let’s describe our newly created Keystore by issuing the following command within the shell.

describe keyspace ExampleKeyspace

The output of the following command should look something like the one below:

This tells us that Cassandra has configured our custom Keyspace and we’re ready to rock!

How to insert data into Cassandra using Hector

Hector is a Java framework that can be used to communicate with Cassandra. In this example, we’re going to take a brief look at how to write a simple row that storages a new user. Please note, this example does not leverage any advance features of Hector. The purpose of the follow example is to demonstrate how to use Hector in order to insert data.

How do I verify the data is in Cassandra?

Now that we have Cassandra up and running, let’s visually inspect our newly created record. We could use the cassandra-cli tool, but it’s not not an elegant solution for this particular use-case. Instead we’re going to use cassandra-gui which is a graphical application that will allow us to inspect the database. Simply download the cassandra-gui.jar and double click on it. It’ll prompt you for the host and port of our Cassandra instance. The one thing to keep in mind when using this tool is that in order to see the records, you must right click on the tree node and select “show 1000 rows“. The panel on the right hand side should then refresh and allow you to explore it.

I hope this article helps to get you started in working with Cassandra and Hector!

More recommended reading

• Cassandra – Data Modeling
• Cassandra Basics by Benjamin Black
• Cassandra’s data model cheat sheet by Charker Nakhli