In the end everything is a CRUD operation.... Need to rethink this one?

In this post, I am trying to compare and contrast two mindsets , One which believes that everything in the end boils down to a CRUD operation and one which believes in modelling behavior .

Till not so long ago, I believed that everything boils down to a CRUD operation, this mindset reflected in the solutions I modeled for a given requirement, I had kind of heard about behaviorally rich models, however I just could not figure out how they were of any use, given that everything in the end is a CRUD operation :)

After having been introduced to DDD and reading a few books and posts on it, I seem to be getting a hang of it and in this post, I am going to take a simple requirement and then model it with a anemic/CRUD mindset and then a behaviorally rich/DDD mindset.

The requirement is fairly simple we are trying to save the details of a customer.

First to go CRUD mind set. You can find the gist here

I am sure this looks familiar to most of us.

So what is the problem with this approach. At the very least the below four

1) There is little intention revealed by the saveCustomer method.
2) The customer class is more like a DTO rather than a domain class.
3) This method can be used more than a dozen business situations, so how does one unit test this method ?
4) This method will need to be changed in more than a dozen cases, it clearly violates SRP.


So now lets go for the behaviorally rich approach.

The customer class may start looking like the below. Have a look at the gist here, it includes a snippet of the application service too.

Now with this kind of modelling, each method has only 1 reason to change :)

We know the intent of each method.

This API also supports a task based UI.

So now the question that arises is, which approach should we take ?

The answer is "it depends on the context" :) .... If  the context we are working on is the core domain we should probably tend towards a behaviorally rich model, else in a lot of cases a anemic approach may turn out just fine.

The behaviorally rich model does involve more thought and work, but in ends up with a much cleaner and more maintainable code base.

The most important thing to take home is that we should debate and discuss if everything should be blindly modeled in a anemic fashion, we do have a very real and appealing alternative , Lets consider it !!!

Disclaimer : A lot of it is directly picked up from the IDDD book ;)

Server side pagination with mybatis

Of late I have just included support for server side pagination in the DDD/CQRS bootstrap project, the project uses MyBatis for querying the read side.

For those who are unfamiliar with server side pagination first have a look here.

So when implementing pagination the kind of information we often need is

The current page Number

The total number of pages

The total number of elements

A paginal component often looks like the below.

You can find the entire API to display a paginal component here.

With pagination you often want to show summary information about the entire result set, but want to display results only one page at a time.

Client API to use server side pagination is pretty simple, you can view it here.

You can find an example of the client API along with the implementation here

Live Reload in action

I just came across Live Reload and thought it deserves a mention. Basically it allows you to see the changes made in the code instantly on the browser without having to refresh.


Steps to get it working

1) Download Live Reload from here
2) Add a plugin to your favorite browser.

Chrome Plugin.

Once you have the tools set, just follow the steps described in the video here

How to get a method call hierarchy in a multi threaded program

This post might be a no brainer for most of you, but I guess its a useful post for some one new to multi threaded applications.

The problem being we often need to figure out who is calling a certain method especially when the method happens to screw our happiness :) , for now lets name the method 'X'

So now this method 'X' is being called from multiple points in our codebase. However due to some race conditions, it happens to blow up when it is called from certain points in the code.

We would like to know the call hierarchy when this 'screw up' happens, the most obvious solution is to debug the application, but the problem with multi threaded applications in general and race conditions in specific is that the problem rarely reproduces when we debug the application.

So we need the application to be running as is, and some how produce a call hierarchy when the issue reproduces itself. A synonym for call hierarchy would be stack trace ;) .

So modify your code base temporarily to throw a exception which you catch immediately and print a stack trace, this way you can easily get the call hierarchy/stack trace.

void methodX(){

try{

throw new Exception();

}catch(Exception e){

e.printStackTrace()

}

// Rest of your code

} 

This way you will always know the call hierarchy for methodX. Obviously this can be manipulated a little to throw the exception only under certain circumstances.

Shortly put exception stack traces can be used to analyse certain class of problems seen in multi threaded application specifically those related to race conditions.

java.lang.NoSuchMethodError: com.google.common.base.Objects.firstNonNull(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;

As promised in the previous post, I am now starting to document some of the issues I came across or changes that I had to do in the CQRS/DDD Base Project as part of the upgrade.

I guess this post is not specific to the project but probably useful to people using the google guava library.

Have you come across the below stack trace ?

Instantiation of bean failed; nested exception is org.springframework.beans.BeanInstantiationException: Could not instantiate bean class [com.google.common.eventbus.EventBus]: Constructor threw exception; nested exception is java.lang.NoSuchMethodError: com.google.common.base.Objects.firstNonNull(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
at org.springframework.beans.factory.support.ConstructorResolver.autowireConstructor(ConstructorResolver.java:288)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.autowireConstructor(AbstractAutowireCapableBeanFactory.java:1049)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:953)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:490)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:461)
at org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveInnerBean(BeanDefinitionValueResolver.java:271)

Are you using the google guava library ? You're answer for this in all probability would be yes.

The root cause for this issue in our case was that the upgrade made in zk-spring-core this new update now brings with it google-collections version 1 as can be seen in the below image.

google-collections gets included

I already had the guava library declared in the pom.xml as you see below and hence the conflict.

The Objects class in google-collections version one does not have the firstNonNull defined and hence the error.

The resolution being we remove the google-collections jar from the class path and keep only the guava library.

DDD/CQRS Base Project Upgrade

Over the past month I have spent some time in upgrading the libraries used within the DDD/CQRS Base Project. This post is meant to document the libraries which have been upgraded and the changes which had to made to ensure that the upgrades work together.

• ZK has been upgraded from 5.0.8 to 6.5.1, primary gain is the built in support for responsive design and responsive components. You can find the complete feature list for ZK 6.5 here

•  Hibernate-core upgraded from 3.6.7.Final to 4.1.1.Final, primary gain is the built in support for multi tenancy, however we have not yet exploited this benefit we will be working  on the multi tenant version very soon. You can find the complete feature list for hibernate 4.1.1 Final  here

• Spring framework upgraded from 3.1.0.RELEASE to 3.2.0.RELEASE, I do not think this has bought as anything in specific, but you can find the complete feature list for Spring 3.2.0.RELEASE here

These are the 3 major upgrades, these upgrades have required us to upgrade certain other supporting libraries and have also made some of the libraries redundant, I will write follow up posts on these changes pretty soon.Till then happy coding :)

 Follow Up Post ZK upgrade brings in google-collections

Cow extends Mamal extends Animal ? Inheritance abused just a little ;)

This is a post which I had in mind for a long time now , about how we tend to use inheritance incorrectly, these are just thoughts and at best guidelines so do not take it too seriously :)

Often in our modelling efforts we try to mimic the real world, so if we had to build a game in which the characters where animals we would be very tempted to come up with some thing like the below



Inheritance

This is probably not the right way to go about modelling our domain. The thing to take note here is that the zoological classification is useful for identification, however it does not necessarily represent behaviour.

Probably in our case here and also in general , interfaces are better suited to represent behaviour. We could consider something like the below

The point I am trying to drive home is in our modelling efforts we should focus more on behavioural representations in the context of the application being built, rather trying to mimic the real physical world.

In the game we are not interested in the DNA structures and hence we completely ignore it in our modelling efforts. Ignoring details which are not important in the context of the application is extremely important. In the context of the game, behaviour could mean

• Mammals which can hold their breath under water
• Mammals with large teeth

Another example to steer you towards interfaces, The famous Square extends Rectangle one.

Geometrically the below makes perfect sense

However from a modelling standpoint Square does not exhibit the same behaviour as a Rectangle, the error comes in when we translate the common statement "a square is a rectangle" into a inheritance hierarchy.

You can read up on LSP (Liskov Substitution Principle) to understand why a Square should not inherit from Rectangle

  Where does this leave us ?

• While modelling think about behaviour before converting statements like "Employee is a Person" into a inheritance hierarchy.
• Consider the use of interfaces before deciding on a inheritance hierarchy

References :

Interface oriented Design

Designing Reusable Classes