For the last two years, Custom House software development team has been making a major push to apply DDD on its projects at both the tactical and strategic levels. These are their stories.

IAnticorruption – A Domain-Driven Design Approach To More Robust Integration

Sam Peng and Ying Hu
June 2007
[Read] [Watch presentation]

Abstract

Custom House's new currency exchange system is integrated with a legacy system. After a few years of growth, the two systems were so intricately tangled that even small changes made in the integration layer would have unpredictable side effects. Refactoring on the integration layer was risky and time consuming. The situation called for a revolutionary redesign.

The solution was to introduce an anticorruption layer to isolate the two systems. This layer encapsulated the translation of conceptual objects and actions between the two systems, insulating the domain layer from knowing the existence of the other system. By freeing the domain layer from performing tasks that were only relevant to the other system, the anticorruption layer allowed additional external systems to be integrated without requiring any changes to the domain layer itself. Full implementation of an anticorruption layer reduced overhead of legacy integration from 30% of total development to 10%.

The biggest challenge in implementing the anticorruption layer is to control the complexity of translation work. This was managed in an innovative way: by building an object model reflecting the implicit model of the legacy system. Our experiences show that an external system need not be object-oriented for its model to be adequately abstracted, and this has proven to be the key to a clean and extensible translation.

So We Thought We Knew Money

Ying Hu and Sam Peng
January 2007
[Read] [Watch presentation]

Abstract

In Custom House's financial system, "money", "rate", "currency" and "markup" are among the key concepts that describe the domain. Without explicit modeling, those concepts appear in the code, but only in variable names of primitive types and sometime in method names for operations whose arguments and return types are all primitives.

In this paper we present the experience gained when Custom House development team applied Domain-Driven Design to explicitly model domain fundamental concepts and abstracted them into value objects. Using code snippets, We show how those concepts were discovered, how we refactored the existing code base to apply the value objects, what difference the value objects made and how they evolve over time.

We also report the pitfalls and stumbles during the process, which are not uncommon for projects that undergo ongoing development work. We show that, with all the incompleteness and imperfection, Domain-Driven Design has gradually accepted into real development process, making a crucial and continuous transformation.