Rich Domain Model Stuck in Legacy System
Brows furrow, fists clench, throats tighten. Our domain logic is lost in legacy systems. I look back at any significant project that interfaces with our mainframe and see lost opportunities. We could have real domain objects interacting with relevant behaviors, but instead we dutifully write dozens of data objects full of getter/setters and little else. We pass off all the business logic and processing to the mainframe.
Even time is a concept we’re asked to check with on the mainframe. Since there’s some strange issues in some of the legacy code and the entire design paradigm was to run everything in a batch mode we can’t even rely on time. Real world time is useless. Setting your time by Network Time Protocol (NTP) is dangerous. Time is just a setting to control when your jobs run.
Mike Witters has seen the anemic domain model as well:
There was almost no logic involved outside of validating UI input. Almost everything from a logic perspective was encapsulated into the legacy systems or database queries: pricing, searches, margin calculations, etc.
We’re still working on it, but if most of your domains are left to your legacy systems you really don’t see the benefits of OO. The promise of a healthy domain driven design remains. Future web mainframe integration projects discussions will center around these ideas.
Ed Gibbs @ July 4, 2007
Great post. I agree with you. You took what I was saying a little bit deeper. In the Portal world many of the _applications_ are just UIs for the systems that do the real work - which is what I was referring to in my post. But, like you I have seen where OO applications are simply created to be adapters for an antiquated legacy system - just trying to buy some more time for the system rather than biting the bullet and starting afresh with what most would consider the ‘right approach’. On one hand I can see the argument to keep the legacy system. These applications have years (possibly decades) of rules and exceptions programmed into them and developers with precise knowledge of how these systems work. Its hard to swallow the expense of documenting and rewriting all of this logic again if the system is working. You have to be able to show tangible benefits of rewriting the system or its logic in a new format in order to convince the bill payers its worth it. On the other hand, it seems like the justification would be easy… write a system with modernized requirements that exactly models the domain so that its not a series of band-aids and exceptions. Plus with the more modern approaches of TDD, Coding with intention, etc you should end up with a system that relies less on having those one or two programmers that stay around with the system for 25 years and knows every single if-statement.
In the case of my post, the client wouldn’t gain a whole lot from rewriting the systems… they just wanted to expose some of the features of a few of their legacy systems to their portal users. So it was the right approach for them.
I’ve seen two sorts of legacy integration projects. One is the simplistic fronting of a legacy application to say combine several green screens on a single web page. I’d agree with you that those are probably the right approach in many cases.
The other type of legacy integration project is adding new functionality and then fronting that with a web front end. Generally that approach is counter-productive. You’re expanding a system that will cost more in maintenance and eventually have to be replaced. You have to mesh OO with procedural development. These projects are really painful and the end result is a wasted opportunity. I think these sort of projects happen more through momentum than anything else because “that’s how we’ve always done it.”
I agree, great post. You have expressed some of the concerns I hear from clients all the time. In fact, the reason I am blog surfing this morning is that I am considering starting a blog to discuss issues around legacy modernization, so I wanted to see what others are saying.
You mentioned two common strategies people tend to consider - wrapping a modern layer around a legacy system to help it interact with some aspect of the outside world, or rewriting legacy systems. The latter is what I hear people call “throwing developers” at the problem. As you know, that’s expensive, time consuming, and there is a history of failed projects that tried that approach.
We offer another alternative. We specialize in transforming legacy systems to newer technologies (OO, SOA, etc.). We do this as a service, using our suite of internal automated tools we have developed over the past 11 years — much faster, cheaper and more reliable than traditional redevelopment.
But this is degenerating into promotion. Like I said, I’m really looking for input on whether a blog about legacy system challenges and opportunities would have a place in the blogosphere. Drop me a line at ajmcallister@tringroup.com if you have an opinion, or check us out at http://www.tringroup.com
It’s a big nasty looming problem as the maintenance programmers on legacy systems start to retire. The worst thing I see is doing new greenfield development projects on legacy systems because we can not because we should.
Sounds like a pretty large problem and not a bad space to target with a business. Anyway send me an email if you do startup the blog so I can add it to my RSS feed.