Pragmatic software development is about knowing which tools solve which problems best. For example, test driven development is wonderful for designing a domain layer. Unfortunately, mapping the UI interaction with the domain layer is often painful and done poorly. Using UI Driven Service Layer Development you can more easily decouple the UI layer from the domain layer.
Your team has tested and developed a domain layer. The classes are well designed and contain correct responsibility. You also have mock screens given to you by a UI designer. Your next task is to make the screens work with the existing domain layer. You should begin by creating the UI & service layer, but stub the service layer. Make the entire application "work" with hard coded data returning from the stubs. Patterns and logical groupings will begin to emerge in the stubbed service layer. This approach lends itself to easily refactoring the service layer to an interface that logically fits the UI. Finally, you convert the stubs into real classes that interact with the domain layer.
The finished product is an service layer that the UI can consume without being tied to the domain layer design decisions.
Hi Jay,
ReplyDeleteInteresting post. Would you like to elaborate more on this topic, I mean longer post or any link to further read about this post?
Tq
Hello deman,
ReplyDeleteThis is the style I used to use when I was developing using c#. I haven't seen other write ups that are similar, but I also haven't been looking for them. Since I've been doing ruby for the past 1.5 years now I don't really have anything new to add to the original post. Ruby tends to have much lighter weight layers so this style doesn't really apply.
Cheers Jay