Technology weblog

Interesting post on DDD, EDA and the Axon framework

Just stumbled upon an interesting post on DDD, EDA and the Axon framework: Axon Framework - DDD and EDA meet together.

Posted at 07:58PM Aug 24, 2011 by Zeger Hendrikse in DDD and CQRS  |  Comments[0]

Discussing CQRS

My colleague Koen en me discussing the CQRS architecture underlying the new version of ABN-AMRO pension services

Posted at 06:36PM Aug 23, 2011 by Zeger Hendrikse in DDD and CQRS  |  Comments[0]

Axon 1.1 resolves issues with HSQLDB 2.0

In this post we mentioned that the Axon framework didn't like HSQLDB version 2.0. However, after migration to version 1.1 of the framework, the problems mentioned in the previous post were no longer observed! Now we can finally expect more sensible error messages from HSQLDB.

Posted at 02:23AM Aug 05, 2011 by Zeger Hendrikse in DDD and CQRS  |  Comments[0]

CQRS and command validation

During the implementation of our CQRS-based application, we initially had discussions where the validation of the commands needs to reside (client side versus command objects) and the precise distinction between validation and business rules. Today I found an excellent post, titled Clarified CQRS, that very concisely and very accurately addresses these issues and more. A lengthy, but very worthwhile post, with over 100 comments already. I surely recommend anybody interested in CQRS to check this post out.

Concluding: applying the CQRS pattern forced us to think over these concepts thoroughly from the start, which is now reflected in an even more robust and maintainable application.

Posted at 08:10PM Apr 13, 2011 by Zeger Hendrikse in DDD and CQRS  |  Comments[0]

Axon framework sample applications

Today I found a site with some sample web applications that are based on the Axon framework. If you need to get acquainted, this is the place to be!

Posted at 05:39PM Mar 16, 2011 by Zeger Hendrikse in DDD and CQRS  |  Comments[0]

Introduction CQRS

Today I found an excellent post on CQRS (Command Query Responsibility Segregation) by Rick van der Arend. A Dutch version is available too: CQRS & de bijkomende architectuur. This post not only introduces the principles of CQRS, but motivates them too, e.g. it is argued that the introduction of event sourcing offers a solution to keep your domain model clean of getters and setters and makes it possible to restore state without performance problems. This is exactly what we found out implementing our current application for booking office rooms (we first tried to go without event sourcing)!

The pictures that are used in the post are also very instructive:

From CQRS & the architecture coming along by Rick van der Arend.

Posted at 03:10PM Oct 22, 2010 by Zeger Hendrikse in DDD and CQRS  |  Comments[0]

Instructive domain-driven design application

Today a colleague pointed me to a link referencing a sample DDD application. This application is authored by DDD gurus such as Eric Evans and Greg Young. We think their code is very inspiring!

Posted at 12:06PM Sep 23, 2010 by Zeger Hendrikse in DDD and CQRS  |  Comments[0]

Howto avoid generation of getters and setters (and why)

The generation of getter and setter methods using an IDE has never felt right to me. Recently I stumbled upon two excellent blog posts on domain-driven design that made these feelings explicit and clear. In fact, I think that everyone should (re)read these posts everytime they are about to activate the "generate getters and setters" feature in their IDE. So let's start reading these posts right now: http://sbtourist.blogspot.com/2006/07/avoid-your-getters-and-setters-part-1.html and http://sbtourist.blogspot.com/2007/10/avoid-your-getters-and-setters-part-2.html.  

Posted at 11:33AM Jun 02, 2008 by Zeger Hendrikse in DDD and CQRS  |  Comments[4]

Relation between domain model, service layer and lazy loading

As stated in my previous post on model driven engineering, the key incentive for using domain driven design is to "reduce maintenance and development by working on the model instead of the code level". This way it becomes much easier to link your code directly to its accompanying functional specifications! A good domain model should at least be "rich" in the sense that:

• The domain objects should contain state and behaviour (business logic), see also the Anemic Domain Model anti-pattern as described by Fowler.
• The objects constituting the domain model should have associations. For example, an account object should be contained in a transaction as well as a balance object, so that we can ask which account the current balance or transaction relates to.

With respect to the latter bullet, the big question is how to properly hydrate the domain objects while traversing the object graph. Hibernate's lazy loading mechanism offers an obvious and widely accepted framework to realize a transparent mapping between the domain objects and the underlying relational data, but when the data are disclosed using JDBC (or a web-services based backend), there seems to be no obvious answer.
[Read More]

Posted at 12:00AM Dec 05, 2007 by Zeger Hendrikse in DDD and CQRS  |  Comments[0]

WebSphere Portal and the OSiV pattern

Abstract

This post describes some peculiarities when working with the Hibernate 3.x and Spring 2.x frameworks in a WebSphere portal 5.1 environment and in particular the realization of the OSiV (Open Session in View) pattern in this environment. A solution is proposed for both IBM API type portlets as well as JSR-168 type portlets.

Introduction

In many web-applications, data that is persisted in the EIS (Enterprise Information System) layer is mapped onto domain objects (c.f. the previous post on domain-driven design). These domain objects "live" in an object oriented world, whereas the character of the EIS layer is inherently relational. This is better known as the object relational impedance mismatch. Consequently, there usually isn't a one-to-one correspondence between tables in the database and the object model implemented in Java. In the remainder of this post, such a one-to-one correspondence will be referred to as a trivial mapping.

It is especially in this area of (non-trivial) mappings, where the Hibernate framework really shines. One may transparently "walk around the object graph", without taking precautions on uninitialized associations (child relations). This is primarily established by Hibernate's "lazy loading" mechanism. However, a proper understanding is essential for this mechanism to work and behave as expected, in particular a proper handling of the Hibernate session management within a web-application context, as lazy loading only works within one and the same Hibernate session, which basically boils down to a transactional cache for persistent objects. This holds even more for Hibernate versions 3 and higher, as it boasts a more "lazy behaviour" by default than its predecessors.

Summarizing, Hibernate session management is both an essential and non-trivial issue to be dealt with, in particular in case of web applications. Luckily, this is precisely where the Spring framework really shines. It solves most of the Hibernate session management related issues in an almost transparent way, meanwhile offering a loose coupling of your (web) application layers, by externalizing all object dependencies via dependency injection.

Hibernate, Spring, session management and portal

As was mentioned in the above introduction, most of Hibernate related "side effects" have already been dealt with by the people that developed the Spring framework, hence it is logical to incorporate the available standard solutions offered by their framework.

In web-applications, lazy loading is essential, since certain associations might not have been loaded until the JSP has completed its rendering of all properties that need to be displayed. As stated before, this requires the Hibernate session to be open as long as properties may be retrieved; hence it is necessary to keep a session open over the full request/response cycle. Although this could in principle also be achieved by including the view in a transaction, it is much cleaner (i.e. much less resource consuming) to employ the former solution, the so-called Open Session in View (OSiV) pattern.

Open Session in View

Keeping the session open for the complete request/response cycle is generally known as the Open Session in View pattern. It is most naturally implemented using servlet filters (available since servlet 2.3), and is all that is needed when doing read-only operations. Spring offers a readily available OSiV filter, where one merely has to configure the filter and its associated URL matching pattern in the web.xml deployment descriptor. In addition, the opened session is transparently made available to the DAOs (via the HibernateTemplate object), so that most if not all associations can lazily be retrieved, without coding a single additional line of code.

Objects that are thus loaded and are kept in an (HTTP) session, are said to be detached while being edited. When such detached objects need to be saved, it is necessary to re-attach these objects to the new session. This is what the Hibernate "save" and "saveOrUpdate" methods accomplish. In practice, this is intuitively done by programmers. Associations are automatically taken care of, as long as the "cascade" property in the mapping files is set accordingly (e.g. "save-update" for cascading on save and update operations).

Since Spring's OSiV filter implicitly configures the Hibernate session to be FlushMode.NONE, it may be necessary to wrap operations that require read/write permission in transactions.

Open Session in View and portlets

When working with portlets, Spring's OSiV filter cannot be configured in the standard way, since WebSphere portlets have their own (proprietary) way of configuring filters: serlvet filter definitions in the web.xml are simply ignored. Unfortunately, filters have to be defined portal-wide, i.e. filters are defined globally and then configured on a per-portlet basis.

This requires the Spring framework JARs to be available to the parent (i.e. portal wide) class loder of the portlets that are actually using Spring and its OSiV filter. Since many portlets are using Struts too (Spring boasts a very nice means to integrate with Struts), this requires the Struts libraries to be available to the parent class loader too. This in turn causes an avalanche of related class loader problems that basically renders this approach useless. More detailed explanation: class loaders cannot "descend" in the class loader hierarchy, hence Struts classes in the web application's WEB-INF/lib directory would not be available to the classes of the Spring framework in case it is located in the parent class loader of the web-application. Also, bear in mind that by default, portlets are provisioned with a PARENT_LAST class loader policy (whereas servlets have a PARENT_FIRST).

So what can we do to fix the OSiV pattern for WebSphere 5.1 Struts portlets?

[Read More]

Posted at 05:51PM Jul 04, 2007 by Zeger Hendrikse in DDD and CQRS  |  Comments[5]