+972 52-548-6969
Impedance Mismatch and System Evolution
Greg Young is talking about the Impedance Mismatch, replying to Stephen Fortes post about Impedance Mismatch from a while back.
Greg and I have a slightly different views regarding the details of many of the things he is talking about, but we are in agreement overall. You might say we take different approaches to the problem, but with the same overall direction.
What I would like to talk about in this post is specifically this statement from Stephen:
My first problem with ORMs in general is that they force you into a "objects first" box. Design your application and then click a button and magically all the data modeling and data access code will work itself out. This is wrong because it makes you very application centric and a lot of times a database model is going to support far more than your application.
Let me start by saying that I absolutely reject this statement:
[The] database model is going to support far more than your application
The database model is private to the application, and is never shared with the outside world. If you need to access to my data, here is the service URL, have fun reading from it.
However, one point that does make sense to deal with is dealing with the data model that is designed using objects first approach, and the implications from the point of view of good DB design.
I have stated many times before that the way I tend to work is by just writing my domain model in my language of choice, and than asking NHibernate to generate the database for me. This is a really good way to get an environment where changing the model has a very rapid feedback cycle, but it doesn't create an optimized data model.
In does tend to create a good / reasonable data models, and I went to production with such models many times. But it is not the best model that you can have. There are cases where you can see that the one to one mapping that this approach use will generate sub optimal solution, and you need to take steps to deal with it.
This tend to be split into a couple of refactoring options:
- Non schema breaking changes - this include such things as adding indexes, jobs for applying statistics, and general maintenance and tweaking.
- Schema breaking changes - this tends to include denormalization, splitting tables, merging tables and in general moving things around.
In most cases, the first option is a mandatory one. I don't add speculative indexes into my model. I only add them as a result of a performance test that shows an indication of a problem in a particular area. I would strongly suggest not going to production without doing this kind of review and applying the appropriate indexes.
The second option is a more interesting one, because it means that you have recognized a better way to model the data in a way that allows better read/write/query. This is also something that most people are extremely reluctant to do.
I have found that in most cases (by no means all, but a decided majority), I can deal with this issue in the mapping layer, and not touch the domain model itself.
End result is that I still get a good model in both the domain model and the data model, but my focus is on the functionality and the business requirement, which tend to speed things up significantly.
Comments
About:
"[The] database model is going to support far more than your application"
In such cases, especially if the old database don't have a very clean design, an O/RM might help, but also the mappings can be very difficult to implement..
Tudor,
I spoke about brown field development a while ago.
I worked with weird DBs before using OR/M, it is not as easy as green field, but it is workable
"The database model is private to the application, and is never shared with the outside world"
I think its worth defining what you mean by application here because, from discussions in ALT.NET forum in the past, I think you mean something quite specific.
For example I've recently worked for a company that had an internal CRM system and an external one (both just Web apps). Both shared controls and the model/database because there allowing the same behavior (with the internal app having more powerful functionality), so would they be part of one application in this discussion?
"[The] database model is going to support far more than your application"
Mythz,
Reports are part of the application.
Ayende-
I wish databases could be private to applications, but it seems that in almost every company that uses databases today, it comes to pass that the database becomes a:
Default integration layer
Reporting API (particularly via views)
Shadow business rule repository (i.e.everything from DBAs re-implementing rules from the app layer defensively to worse)
It is also endemic that reports are seen as something entirely different than the application, so much so that a vibrant market for independent reporting tools exist.
I am not saying it is right, but I am saying it is reality. And in some places, you have DBAs and others whose job security means keeping this reality in place, which means that for the person to move the needle to private data, there is a lot of work cut out, most of it more human engineering and less software engineering.
Just sayin.
Aaron,
I don't disagree that this is the situation in many cases. I am saying that it should not be this way, and that we should act to ensure that we do not keep existing bad practices in place.
"The database model is private to the application"
Imagine you work at a company/client that is the result of 4 mergers. Or even one.
This oftentimes isn't even remotely possible. Talking about 'bad practices' doesn't really apply.
Time for the Anti Corruption Layer
Product isn't endorsing that, so it isn't allowed.
What do you mean by product isn't endorsing that?
Product (division/department/whatever) determines what work gets done according to its own prioritization. They generate billions of dollars through the system, so they don't care about stuff like anti-corruption layers, only high level customer requests and/or high-paying contractual bids.
What is the cost of high level customer requests or contractual bids?
If they are making money using this approach, that is wonderful for them, and they should continue.
I would watch out for technical debt and the possibility of a grinding halt, but if this is sustainable over the long term, than you have a sweet spot and should remain there
Depends on what you mean.
As a software developer, I would not wish the system on anyone.
But, from a business perspective, trying to 'fix' a cash cow is too risky. IT people (myself included) are very well known for having brilliant architectural ideas that end up being completely f'd up in implementation, and even if there is only a 5% chance of it happening, it's still a legitimate decision to say "nope, down with your anti-corruption layer" or whatever.
Test comment for Ayende per our email discussion. You can delete
Comment preview