Tuesday, March 2, 2010

Domain Driven UI

Not so long back I read this book Domain Driven Design, its an awesome book and helps you understand a lot of business patterns.

Reading the book set me thinking in terms how can I be clean with respect to my Domain while not completely altering my thinking style and by leveraging the existing code.

Conceptually it says have a clear domain model which focuses on your domain instead of technology concepts and then build all kinds of persistence and presentation code around it. Once again a little common wisdom like persistence ignorance and its extension presentation ignorance comes to mind. Its easier said than done. The persistence ignorance has been tackled by many ORM frameworks such as Hibernate, iBatis, ,

This set me to think about presentation ignorance i.e. I was trying to arrive at something where the UI is completely separated from the backend code i.e. There is no need to transformation from ORM Object to Domain Object to a Data Transfer Object to a Value Object to a Page Object to Request Atribute and parameters and then have JSP. I started to think how the world would look like if the pages directly spoke to backend instead of going through a web container. 

Hmm.. I was at an IBM workshop recently and they mentioned that MQ now has its own web server so you can DIRECTLY post messages from your pages to your MQ no need to worry about writing your app. Think about it, now all that you need is for every DBMS to also have a web front-end configure queries and you are done with CRUD operations or if you are in the service world the SDOs. The reason why I state this is vendors are already going along these lines. 

Conceptually this makes things really simpler with respect to having an access integration strategy. I mean portal server JSR 168 is great but what its trying to tell you is in order for you to develop highly interactive applications that can be embedded into a single access integration layer develop it in Java. I am going to plead ignorance on JSR 286 and I am open to your views

Anyways I deviate from the core point which I want to express. My idea is to have a clear domain model and then declaratively instrument it to handle all of the non-functional requirements (network latency, usability...). Being coal-faced I started looking around for frameworks that will help me do this with my core architectural ility, Buildability :). First thing I discovered was the sophistication in Javascript by the way of JQuery. Its a great framework. I would suggest JQuery In Action  as a starting point if you seriously want to give it a shot. The next thing I discovered is JSON, as an alternative data protocol to XML. I was trying to create a Flash type application using HTML where the user interface's contract with the backend was XML except in this case JSON. Now I wanted a way to serialize Java Objects into JSON and JSON Objects back into Java so that my business logic could integrate seamlessly with my UI. (See how I used the word "seamlessly" seamlessly, I will tell you what I was thinking shortly). JSON-Lib did exactly that. 

So the big idea was to do something like this

 Domain Driven UI

So I set out to do this task to see how far I could go with my idea. What follows is how I did it and my conclusion. Of course I am not going to walk you through every detail because web is not for in-depth reading (there is a reason why the killer app is called the "Browser" - Thank you Fortune Magazine)

Listing of Instrumented HTML
Couple of things to notice here
  • AggregateRoot - Domain Driven Design Terminology to specify the standalone root of a business entity. In this case this is a heuristic to the Javascript to utilize root from the JSON being marshalled
  • domainEntity - Specifies the Object type that is being painted, you can paint more than one type of domainEntity
  • Field Names are then directly mapped to the appropriate attribute names i.e. when you see a firstName it directly maps to Person.firstName, again you can have a mix and match of attributes here too
  • Option List - This is a service call to get the information for this reference data by asking for Person.gender so the page creation remains independent of your representation
  • The input heuristic is also used in packing the json back when information needs to be sent to server.
(If you are too interested in this, send me a note I can walk you through a more detailed example).

Now let me show you what the code does. I plugged in a custom Request Processor that would take in the JSON and convert it into object. The seamlessness done through reflection (Doh !!). I use a bunch of custom forwards to inform my processor of the Domain Object to use and then use the converter to convert it

Listing of the Domain Based Custom Struts Request Processor
Why did I use Struts: remember my constraint Buildability ? Ok.. so I have all this now how does the processing logic look like ? The business logic works of pure domain objects. Notice the complicated business logic of printlns using the object directly
Listing of Struts Action

Finally the output JSP merely streams out the HTML. Here is the struts-config listing of a sample action

Listing of Struts Config
My conclusion was I was able to do this pretty successfully. The only cons I could think of was
  • Performance issues because of reflection
  • Too much of work done on the front end and requires some heavy lifting on javascript
  • Some discipline with respect to how to name the form fields
But the pros just outweigh the cons in my mind. I am not able to think of any other reasons. Not to mention, I could write up a google gadget of my UI and embed it into you know where. You could also have a true portal architecture where I could have interactive portlets

What issues do you see ? Is there something I am missing ? Are there frameworks available that already do this (Other than Naked Objects). Dont also tell me about JSF or Ext JS I am not ready to write something that writes something that generates something and the generated something generates HTML. What are your views, shoot back. If you want the complete sourcecode or eclipse project shoot me a note with your name number (and credit card number :) ).

No comments:

Post a Comment