Getting started with DDD when surrounded by Legacy systems II, by Eric Evans

I got this email a month or so back. Not sure if I should re-post it or not.

It has two parts,

1. It advertises the up coming DDD courses in NY, Denver and London. 
2. Then Eric describes how to get started in a legacy environment - (part II).

The parent website is here: http://domainlanguage.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

DDD IMMERSION

ENROLL EARLY FOR SUMMER CLASSES

• July 9, New York, NY
• July 10, Denver, CO
• June 11, London, UK

More dates, course descriptions, and registration here  »
Or call us at: (+1) (914) 861-5264

GETTING STARTED WITH DDD WHEN SURROUNDED BY LEGACY SYSTEMS II

STRATEGY 2: AUTONOMOUS BUBBLE

by Eric Evans

1. Cutting the umbilical
2. The Synchronizing ACL
3. Bubble vs. Autonomous Bubble

CUTTING THE UMBILICAL

In a previous newsletter I discussed the "Bubble Context" as a way to get started with DDD when there is not much organizational commitment. The bubble context is completely dependent on the parent context, drawing all its data through an anti-corruption layer (ACL) like an umbilical cord. You can use that strategy when little else might work. However, it has its limits.

Almost all software uses data that comes from other contexts. A lot of interesting domain logic revolves around combining data from different sources and reasoning about it. Even with one source, there may be a significantly new way of thinking about the data that is fundamental to the desired new functionality (a new way of abstracting the domain, i.e. a new domain model). Sometimes this is done in ways that tangle the systems together and prematurely limit design freedom. The bubble context is quite natural way to start with such an undertaking because the team can experiment with models and combinations in isolation from the legacy system, while the Umbilical ACL obtains and translates the data with minimal impact to existing systems.

The Autonomous Bubble is distinguished by the ability to run its software, for a time, cut off from other systems. Information may start to get stale, requests to external service requests start to queue up unfulfilled, but the internal behavior of the software continues to work. Whereas the Bubble Context obtains its data from another context when it is needed, via the umbilical ACL, the Autonomous Bubble typically has some data store of its own. The data store could be in-memory – the storage medium is irrelevant – but the data is in the form native to the context. This is not just a cache of frequently or recently used data. In fact, an umbilical ACL could cache data as a performance enhancement. The point of the local data store is that the overall evolution of the model and design in this context is much more loosely coupled to other contexts. It should be possible to test such a subsystem without mocks of other subsystems.

Main Characteristics of the Autonomous Bubble Strategy

• Needs organization committed to significant new development with new design approach.
• Allows new data to be collected and used without involving legacy.
• Allows decoupled "product" to evolve.
• May progress from Bubble Context as development is scaled up on a successful pilot project.

SYNCHRONIZING ANTICORRUPTION LAYER

An autonomous context has its own data, sufficient to its core functions, organized according to in its own abstractions. To enable this, the ACL takes on the responsibility of synchronization between data stores in two contexts, which do not depend directly on each other. This ACL activity is asynchronous with any activity in either context, with a service level agreement (SLA) regarding the freshness of the translated data.

Synchronizing ACL

Compare this with the Umbilical ACL of the Bubble Context here

The Nightly Batch Script: Low-tech Synchronizing ACL

Asynchronous synchronization with an SLA sounds more daunting than it is. It can be quite low-tech and examples are all around us. A very familiar implementation of the Synchronizing ACL is the “nightly batch”.

Now a typical nightly batch script does all sorts of things, some of which include important business logic. But, in my observation, one thing most of them do is to update one data store based on another. This could involve importing data from a file. It could involve kicking off a SQL script taking data from one table and transforming it and inserting it into another. It takes many forms, but look at a nightly batch script and you’ll probably find a Synchronizing ACL mixed in there.

Typical nightly batch script has:
• SLA: Open of business, next business day
• Unnecessary coupling: Synchronizing ACL mixed in with once-per-day business logic
• Unnecessary coupling: Multiple ACLs to multiple contexts lumped together.

If you are trying to establish an autonomous bubble, and you think your translation could be handled as part of a nightly batch script, then make sure you isolate the data copying and translation for your particular context into modules (one per context you are drawing on) which can be kicked off by the script. Don't let it get tangled into the spagetti. You need a decoupled synchronized ACL to pull off an autonomous bubble.

Messaging and Domain Events: A Stylish Synchronizing ACL

A more flexible approach to synchronizing uses messages carrying Domain Events. This can be nicely integrated with other event-driven architectural patterns. This approach can support a range of SLAs, and can update a system while it is being used, while batch scripts typically run while systems are off-line.

People discuss the use of messages and events for integration quite often, but usually they don't talk explicitly enough about what happens when a message crosses a context boundary. Just remember, any information crossing a context boundary must be translated. Messages are not somehow neutral. They are always expressed in some language based on some system of abstractions (a model), and we should not let them enter a context that uses a different language and model.

ACL translating Domain Events

Many ways of implementing a Synchronizing ACL are in use and more will come in the future, so I won't try to catalog them. Any mechanism that can update a data store in one context based on data in another, translating along the way, and can do this asynchronously, and without introducing any dependency on it from either context, could be used to implement a Synchronizing ACL. You probably have Synchronizing ACLs in your system now, although they may be tangled with other responsibilities

BUBBLE VS. AUTONOMOUS BUBBLE

The first two strategies I've described each create a "bubble" context, and in this sense they are very similar, and resemble each other when looking inside the bubble. However, the difference in the relationship to the legacy contexts leads to a significant difference in the options for what you can do within the bubbles.

The "Umbilical ACL" from the first strategy gives us as little architectural overhead as possible, but allows no data to be used that can't be mapped from a context continuously attached. Any new information that does not already exist in the legacy system somewhere must be added to the legacy system somewhere, even though it will not be used there! Then it must be mapped into the bubble context, increasing the dependency between the two systems. Clearly this is not the strategy we want once we are introducing significant new information.

In contrast, the "Synchronizing ACL" gives more autonomy to the newly formed context. This autonomous bubble has its own data, some of which is mapped from another context, but it can also have data of its own. So development in the autonomous bubble is not so tightly bound to the older contexts. The model in this context can be more innovative and grow more freely, and a fresh new product can be created.

NEXT TIME: EVOLVING A MODEL IN A BUBBLE

Design freedom is the point of a bubble. The bubble context with an umbilical ACL gives a little freedom, while the Autonomous Bubble can give us a lot if properly managed. However, in the actual unfolding of a development project, there are many ways this can go wrong and bog down before the team has reached its goals. In my next article I'll give some guidelines for process and design that help the team retain and even increase their ability to change the model as the project goes along.

Strategic Design - Responsibility Traps lecture by Eric Evans

This is an Excellent talk by Eric. 

Full of common sense and good observation.

The talk is essentially about using the Anti-corruption layer as a way to concentrate on the Core Domain.

Anti-corruption layer? A way of embracing the reality that often times it's better to leave the legacy system, the ball of mud, and concentrate on the new core features.

The example of what can be core domain and sub domain is excellent and simple.

Eric chose the rating feature used by Amazon and by Ebay.

In Amazon the star ratings are very handy but their business model does not depend on the feature. It is unlikely that the visitor to the site will purchase based on this feature. Maybe sometimes, but not significantly.

However in Ebay, the star rating is absolutely crucial in developing the trust between the seller and buyer. This therefore is key and is core domain.

Summary
Eric discusses the need for strategic thinking and how early design decisions have major impact on the organization and the entire development process. He uses the lens of DDD Strategic Design principles (emphasizing "Context Mapping" and "Distilling the Core Domain") to show how to avoid strategic failures and achieve strategic successes. Winning strategy starts with the domain

http://www.infoq.com/presentations/design-strategic-eric-evans

Work in the Core Domain - Part 4 in the book!

Getting started with DDD when surrounded by Legacy systems, by Eric Evans

Getting started with DDD when surrounded by Legacy systems

STRATEGY 1: BUBBLE CONTEXT(Part 1 of a series by Eric Evans)

• Why we need the bubble
• How we form the bubble
• What becomes of the bubble

WHY WE NEED THE BUBBLE

We say that effectively applying the tactical techniques of domain-driven design (DDD) requires a clean, bounded context (See September 2010 newsletter). This can be a daunting requirement when your work is dominated by legacy systems. These systems are often tangled, and even when they are orderly they are usually not suited to DDD. In a series of articles over the next few months, I'll describe strategies for getting started with DDD when you have a big commitment to legacy systems.

All of these strategies will be ways of establishing a new bounded context. Attempts to employ the DDD tactics in the context of a legacy system almost always disappoint. One of the fundamentals of DDD is that we choose a model (by which we mean a system of abstractions) well suited to the problem at hand, yet a legacy system already has an established model, albeit implicit, and this model can seldom be changed with a reasonable amount of effort. Even if the legacy model could be changed, the new model might not suit the legacy functionality -- the change could undermine what the legacy system was always good at. On the other hand, simply adding objects that express a distinct model without changing the ones already there will lead to conflicting rules and concepts.

Read more ...

Will DDD work for your team? by Eric Evans

Will DDD work for your team?
Four prerequisites for Domain-driven Design

by Eric Evans

While the Strategic Design techniques of DDD can be applied in many situations, development based on subtle domain models has some demanding prerequisites. If you don't have them, it is a waste of effort to leap into application of DDD at the tactical level.

Instead of grinding your gears trying to express elegant models, you'd do better to direct your efforts toward establishing these conditions for success.

This is real life, and nothing is perfect. However, you really must have some form of the following,

• Access to domain experts
• An iterative process
• A clean, bounded context
• Skills on the team

read more at...

The Elephant test. It's difficult to describe but you know it when you see it.

I think it's an Indian story but probably our most famous version was by John Godfrey Saxe.

It was six men of Indostan

To learning much inclined,

Who went to see the Elephant

(Though all of them were blind),

That each by observation

Might satisfy his mind

The First approached the Elephant,

And happening to fall

Against his broad and sturdy side,

At once began to bawl:

"God bless me! but the Elephant

Is very like a wall!"

The Second, feeling of the tusk,

Cried, "Ho! what have we here

So very round and smooth and sharp?

To me 'tis mighty clear

This wonder of an Elephant

Is very like a spear!"

The Third approached the animal,

And happening to take

The squirming trunk within his hands,

Thus boldly up and spake:

"I see," quoth he, "the Elephant

Is very like a snake!"

The Fourth reached out an eager hand,

And felt about the knee.

"What most this wondrous beast is like

Is mighty plain," quoth he;

" 'Tis clear enough the Elephant

Is very like a tree!"

The Fifth, who chanced to touch the ear,

Said: "E'en the blindest man

Can tell what this resembles most;

Deny the fact who can

This marvel of an Elephant

Is very like a fan!"

The Sixth no sooner had begun

About the beast to grope,

Than, seizing on the swinging tail

That fell within his scope,

"I see," quoth he, "the Elephant

Is very like a rope!"

And so these men of Indostan

Disputed loud and long,

Each in his own opinion

Exceeding stiff and strong,

Though each was partly in the right,

And all were in the wrong!

Moral: 

So oft in theologic wars,

The disputants, I ween,

Rail on in utter ignorance

Of what each other mean,

And prate about an Elephant

Not one of them has seen!

Eric Evans gave a good lecture on legacy systems which started by using this 

The Heart of Software

The heart of software is its ability to solve domain-related problems for its user. All other features, vital though they may be, support this basic purpose. When the domain is complex, this is a difficult task, calling for the concentrated effort of talented and skilled people. Developers have to steep themselves in the domain to build up knowledge of the business. They must hone their modeling skills and master domain design.

Yet these are not the priorities on most software projects. Most talented developers do not have much interest in learning about the specific domain in which they are working, much less making a major commitment to expand their domain-modeling skills. Technical people enjoy quantifiable problems that exercise their technical skills. Domain work is messy and demands a lot of complicated new knowledge that doesn't seem to add to a computer scientist's capabilities.

Instead, the technical talent goes to work on elaborate frame-works, trying to solve domain problems with technology. Learning about and modeling the domain is left to others. Complexity in the heart of software has to be tackled head-on. To do otherwise is to risk irrelevance.

In a TV talk show interview, comedian John Cleese told a story of an event during the filming of Monty Python and the Holy Grail. They had been shooting a particular scene over and over, but somehow it wasn't funny. Finally, he took a break and consulted with fellow comedian Michael Palin (the other actor in the scene), and they came up with a slight variation. They shot one more take, and it turned out funny, so they called it a day.

The next morning, Cleese was looking at the rough cut the film editor had put together of the previous day's work. Coming to the scene they had struggled with, Cleese found that it wasn't funny; one of the earlier takes had been used.

He asked the film editor why he hadn't used the last take, as directed. “Couldn't use it. Someone walked in-shot,” the editor replied. Cleese watched the scene again, and then again. Still he could see nothing wrong. Finally, the editor stopped the film and pointed out a coat sleeve that was visible for a moment at the edge of the picture.

Eric Evans - Domain-driven design: Tackling Complexity in the Heart of Software, 2003

Domain-Driven Design Community

Eric Evan's book is excellent and the "method", or at least, this way of thinking when given a design problem seems so natural. He's active in the Domain-Driven Community. First published in 2003 I think.

Eric does courses too. His courses are in NY but others are held in London

Eric's book is not in Kindle (so obviously not in iBooks). Domain-driven Design: Tackling Complexity in the Heart of Software

Good essay on the Domain Model (from 2006)

Essay: The Database Model is the Domain Model
By Frans Bouma

Preface

To work with data on a semantic basis, it's often useful to specify general definitions of the elements a given portion of logic will work with. For example, an order system works with, among other elements, Order elements. To be able to define how this logic works, a definition of the concept Order is practical: We will be able to describe the functionality of the system by specifying actions on Order elements and supply with that a definition of that element Order.

This Order element contains other elements (values like the OrderID and ShippingDate) and has a tight connection with another element, OrderRow, which in turn also contains other elements. You can even say that Order contains a set of OrderRow elements like it contains value elements. Is there a difference between the containment of the value OrderID and the containment of the set of OrderRow elements? The answer to this question is important for the way the concept of Order is implemented further when the order system is realized with program code.