Taking control of your application development – managing dependencies

If we look at wikipedia article for coupling, we’ll find that it’s synonymous with dependency. Just about everybody know that coupling is bad and yet you can find a dependency graph like this:
 
Presentation->Business->Data Source
(meaning Presentation depends on Business that Depends on Data Source)
 
Assuming the implementation is not superficial and nothing like typeless datasets are being passed directly up to the Presentation, let’s look at what this graph allows:
– direct use of Business abstractions in Presentation (good)
– no direct coupling of Presentation with Data Source (good)
– Data Source driving the interface/protocol for communications with Business (bad)
– testing of Data Source in isolation (worthless, because unless our Business abstractions are just DTOs we are not involving any Business rules)
 
And what it doesn’t allow:
– testing Business in isolation (bad)
– testing Presentation in isolation from Data Source (bad)
– substitution of Data Source with another implementation (bad)
– and related to the previous, reuse of Business w/o the reuse of Data Source (bad)
 
Does that look like Pit of Success to you? I don’t think so.
 
Here’s another graph suggested by Domain-Driven folks like Eric Evans and Jimmy Nilsson:
 
Presentation->Business<-Data Source
 
This graph allows us to keep all the good stuff from the previous graph and eliminate all the bad stuff.
 
I want to elaborate a bit on the substitution of Data Source implementation. While this might seem unlikely, recent years have proven that Data Source and Presentation are the most likely targets of change (once the Business functionality has been achieved).
Imagine porting your ASP.NET application to Silverlight and you’ll realize:
1) Silverlight means you’re adding another application (client for you web-app server!). There are of course other likely clients that you might get. If you’re like me you’ll want to involve the Business rules as early as possible and that means… Business layer, hopefully reusing the implementation you’ve created for the server.
2) the change is not unlikely given the feasibility
3) the change is not feasible if you have to drag the Data Source implementation along.
 
It might seem at first that we have a circular dependency here, but that’s not the case.
What are the Business abstractions that would allow as to do it? What is required from the infrastructure to let it happen?
Tune in later for the spectacular conclusion!
Advertisements
Taking control of your application development – managing dependencies

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s