Building the often needed anti-corruption layer
The fear of the LORD is the beginning of knowledge, But fools despise wisdom and instruction. — Proverbs 1:7
“Agile Joe” and I were chatting about the challenges of building on top of existing application platforms, specifically ones like Microsoft CRM (which Ayende is painfully dealing with) and Commerce Server 2007, which is what I’m dealing with on my current project. Joe pointed out the importance of building an anti-corrruption layer. And I couldn’t agree more. In fact, since I’m using DDD as much as I can on this project, we’ve been able to deliver early customer demos showing working features, end to end, using stubbed repositories.
To get a better picture, this is basically how the design of the system is shaping up so far:
| MVC Web UI | MonoRail of course. 🙂 |
| DTOs (Screen-specific) | 2 way databound using MonoRail’s most excellent DataBinder |
| Thin Service Layer | To simply act as a facade to expose business operations and to handle the DTO => Domain Object mappings |
| Domain Model | With all the entities, value objects, factories, specifications, etc. that you would expect. I also keep the public interfaces to my Repositories in my domain model, but the specific implementations of them in a Persistence layer. |
| Persistence Layer – Stubbed | These are just some in-memory repository implementations which have allowed us to demonstrate working features to the customer very early in the project. |
| Persistence Layer – CS 2007? | This one is yet to be, but is what I have in mind when we start integrating with CS 2007 soon. This would basically act as our “anti-corruption layer” between CS 2007 and our domain model. |
It seems the recommended approach for implementing an anti-corruption layer is to treat is as another Service Layer. From our perspective, I don’t see much of a difference in using Repository implementations in the same way. Especially since in our case, most of our integration with Commerce Server will be dealing with persisting/retrieving data. On a related note, I’m starting to realize that MS application platforms like Commerce Server are nothing more than a pre-built legacy database for your application. Hence the need to localize the nastiness involved with extending and integrating with it, in an anti-corruption layer.
The one advantage I do see by treating this integration layer as another Service Layer, is in the fact that in reality there will be a lot more going on behind the scenes besides just a bunch of persistence method calls. Since Commerce Server has its own wannabe entities in the form of weakly-typed datasets (yes! you heard that right) and untestable classes, we’re going to have to build another set of mappers that can translate between our domain model and our extended CS 2007 “entities”. Along with things dealing with the CS 2007 context, etc.
We’ve already identified the need to have an extensive set of automated integration tests to drive out this anti-corruption layer. So I’m sure I’ll have a lot more to say on that as we progress. Unfortunately it looks like it’s going to require some fairly complex test set up logic to get a test instance of CS 2007 configured in an automated fashion.
Like most instances where you have to extend and integrate with an existing platform such as Commerce Server, I keep wondering if all this time we’re having to spend will be worth it vs. “rolling our own” as they say. Guess we’ll see.
Any thoughts on this approach? Am I just completely mad? 🙂