Welcome Welcome to our blog about all kind of topics that are related to software development. We blog about:
SOA, BPM, EDA, ECM and all the other buzz words. Beware some post might not be so common as you think. We are not scared to go against main stream thoughts.
Technologies like java, maven, springframework, OSGi and front end technologies and frameworks like jQuery, DWR, Flex.
Finally to make this happen we need tools and of course a Mac (well some of us do). So we blog about that as well.
Linked in We now have a linked in group, join the group if you are a regular reader and want to see who else reads this blog.
 |
By Allard, on April 6th, 2009
As many other developers, I’ve been used to the fat service layer and the anemic domain model of the transaction script pattern. In that programming model, immutability is pretty much as rare as a Dodo. However, I have been investigating the rich domain model pattern lately (as you can read in my previous post) and more importantly, a good migration path for “transaction script” developers to get acquainted with the rich Domain Model, a design pattern that has been heavily underrated (and misunderstood) by many.
In this post, I will explain some of the advantages that immutable domain objects bring us, while showing that some of the seemingly problematic side effects aren’t really that problematic.
Continue reading The power of immutability in a Rich Domain Model
By Ben, on December 27th, 2008
Introduction
Author’s note: this is an article that I co-authored
with a colleague, Robert van der Steen. It has also been
published in our company newsletter.
Many of the applications we write for our clients nowadays use the service paradigm: a dedicated and often reusable component within the application that is responsible for a particular task or process. Such components are often written and used in such a way that a component is instantiated once and reused often within the runtime of the application (such as a web service or a Spring managed bean).
Using components in this way is a very resource-friendly way of constructing an application; resource-intensive objects are created only once and reused instead of having to be recreated and reinitialized for each request. However, they do make it necessary to pay special attention to issues that arise in reuse and concurrent use — specifically state management. A common technique to avoid such state problems is to build stateless components.
Unfortunately, mistakes happen in software engineering. Sometimes team members introduce state to shared components without thinking about it. This article discusses using the Memento pattern as an easy way of transforming a stateful into a stateless service.
Continue reading Using the Memento pattern to solve thread safety issues
By Ben, on August 9th, 2008
One of my current projects is responsible for delivering a library of functions that are used by several applications being built and maintained at our customer. One of those functions in particular is quite central to the operation of all the applications that use out library and is responsible for collecting, transforming and combining data from many different sources (essentially it is an orchestrating function). This function has a classical codebase, in the sense that the codebase started out being much smaller than it is now and with fewer tasks but has since grown. The library function is being developed continuously and will be expected to meet more and more requirements as more and more data must be collected and correlated. The problem, as you can imagine, is that the codebase is becoming unmanageable as more and more code goes into it. So we are faced with the question: how can we refactor the existing codebase to improve manageability?
As mentioned before the function in question is essentially an orchestrator, collecting data from several locations and combining these different data into one package. The collection of data is not random, however: some requests depend on the results of others, creating a natural partitioning of the function’s code into tasks with an internal ordering. Of course, this sounds like a classical orchestration setup and the first suggestion might be to use an orchestration tool like a BPEL engine. However, integrating a BPEL engine into the library seems like overkill given the current size and complexity of the function (and doesn’t fit well with the rest of the library). So instead my project is going to attempt an intermediate solution between the current pile-of-code architecture and a full orchestration tool: the Life Cycle Pattern.
Continue reading The Life Cycle Pattern
|
|
