Data Driven Or Domain Driven Application?

9 Comments

• I strongly disagree with your arguments. In the business world the life blood is data. Everything should be data driven.
  
  Let's talk about why in business world or for any data centric application, objects are only a containers for data. For example, in a company, we have employee, then instantly, after so many years of OOP, you will think employee is an object. Is employee really an object? Does employee have any behavior? You might think it does. Why you think employee have behavior? The illusion comes from another type of application, such as a game application. Let's say, it's a shooting game and there are soldiers. I have to say, soldier is a real object, because it has attributes and behavior. A gaming soldier can really walk, shoot, run. Back to the employee model, what can an employee in a data centric application do? Does a data centric employee have any behavior? You might say, well, employee can have CRUD operation/behaviors, but in reality, CRUD operations are not intrinsic to employee; some thing else is doing the CRUD on the employee, not employee themselves. So in the data centric applicaiton, employee has no relevant behavior. Do you agree?
  If employee has no behavior, then it is a data container. And in reality, before computer is invented, employee data are presented in a paper form, with fields people can fill in. On the other hand, the gaming soldier is quite different. Let's see, if you are presented with 100 gaming soldiers in a room, every one of them have to be alive. They have to be able to respond to your gestures. Say, you shoot them with a machine gun, they have to fall to the ground. What can a data employee do in an application? Is it acting the same as a gaming soldier? Absolutely not. When an employee is presented to you, it's in a form of fields, in another word, it's a dead data container, it doesn't respond to your input. You might say, how about validation? Well, validation is a data issue, right? Employee's name can be 50 varchar long or 100 varchar long and there are many places you can place that validation. It's that way because validation is not intrincit to employee as an object.
  
  It's painful to understand the code to see the business is because it's spread everwhere, in compiled module or scripts. If you put them all in stored procedures, then it's much easier to chase the business rules, etc.
  
  I have worked on multiple application re-write. We just threw away the application code and keep the database. Dats is more important and last much longer. On the other hand, the application code has gone through a lot, ODBC, DAO, ADO, ADO.NET, LINQ to SQL, ADO.NET EF? How many are in the pipeline? But if you keep all your business rules in the database, you are safe, T-SQL or PSQL haven't undergone so much revolutions, have they?
  
  As I said, data is the life blood of a business. It's only natural we go from data driven design instead of domain driven design. When you do DDD, you are one layer removed from the real business. It's an abstraction, but also you are creating some impedance along the way. From my experience, a good database design goes a long way .
  

• "When you have a table that has address in it, expressed in several fields such as city, street, postal code, province, and country – how exactly you are going to validate that the postal code matches the province, and province the country"
  
  That's a good question and a great challenge for both DDD and Data driven design. In my experience, a Data driven solution for this issue is much more efficient and perfomant than the DDD one.
  
  For a DDD solution, you probably have to load all the related collections of postal code, provinces and countries; when you are talking about a global solution, the sheer number of objects will bog down the system. That's what I have witnessed a Java/Hibernet solution that does simple things too slow that angers every user of the system and eventually we have to throw away tons of JSP/Java bean/Hibernet code and mappings.
  
  On the other hand, the validation is much easier to implement if you think that those are just data and a stored procedure will encapsulate the logic pretty well. The issue I see here is that competent SQL programmers are hard to come by. People discredit SQL because they don't invest enough time in the language, especially try to understand SQL is a set based language, cursor is evil. If you think about it, Object is indeed a layer removed from the real data and different languages with their unique idioms complicate the understanding of the data. DDD with its pure design might be a good idea, but when it comes to implementation, it loses its affinity to the data. On the other hand, SQL is directly interacting with data. Also when it comes to reporting, DDD is really hopeless, because reports are all about data, not constrained to a pre-defined object model.
  
  In a real world design to automate a business process, we gather the paper forms, spreadsheets and come up with an ER model, from that ER model we generate our objects. When ER model changes, we regenerate the generated part of the code. It seems to me that it's a more acceptable practice. Also in my experience so far, anything comes from DDD and object purists suffer from poor performance and extra-long cycle of development.
  
  I agree that Data driven approach doesn't sound as cutting edge as DDD, but it gets the job done nicely. And users don't care about what you use, DDD or otherwise; if the application is slow and cost too much to run properly, it's not good. DDD has a much higher price tag if you compare your DDD solution vs your Data driven solution.
  

• About the old application written in VB script and ASP. I have the same painful experience because I have to re-write some of them. I think I become a re-write expert:).
  
  The problem is not with design, the problem is with implementation. I am not trying to discount VB programmers, I started as one. But I majored in computer science so I know that there are right way and wrong way in VB coding. But unfortunately many VB programmers don't have those concepts. They just try to get the job done in whatever way you know how. Actually if your old app were coded by people who read "Code Complete", the situation could be much better.
  
  In my view, it's not a design issue; it's an implementation issue.
  

• @Wilfred,
  thank you for asking. In no way I can represent a person who's proficient with DDD, but I can definitely express my opinion in the matter.
  First, I agree that simple forms-over-data does not require entities (what NHibernate is good with). But NHibernate can do more than that. It can be used for reporting (strongly typed one) - something I learned recently. It also depends how much non-data logic you have in the application (what I would call business rules). And the last and not least - what's your teammates skills. If they know absolutely nothing about NH and not really willing to investigate alternatives, I would recommend to be careful, this is a thin ice and bully walking on it might end up sad for you.
  
  Probably picking up NH book and reading what it can do the best would be a good start. Also lots of resources are out there to give you valid answers. I would try NH usergroup. And, good luck in your project.
  

• @Sean,
  thanks for your reply. and i also favor to use Hibernate to be the Data access layer.
  but about reporting, do you mean using report queries ? or batch fetching ? do you mind giving me some more information.
  
  In fact, my teammates have no idea about Hibernate, Swing, MVC model, Design patterns... Although i'm not an expert in these stuffs, i'll try to build the application framework and make some examples for them. And i already recommended some books like 'hibernate in action' to them. Hope they can enjoy learning new things in short time.
  
  Thanks, Wilfred
  

• @Wilfred,
  
  will be glad to provide whatever knowledge I have. Be careful with the team, especially if all of the listed items are all new to them. Do not alienate them against you. Forward your specific questions to me at feldman[dot]sean[at]gmail[dot]com
  
  

• @Jiang,
  
  What can I tell you - your way, you go it. I am not going to waste my time and effort, especially someone like yourself. Good luck to you and your customers :)
  

• @Jiang - Wow, you finally found 1 supporting argument in almost a whole year.
  
  I also notice that the last update to this obviously world-renowned "intelligent commentator's" Geocities web-site is 8/27/2006.
  
  Consider me convinced!
  
  The unwavering faith being shown in data-driven applications requires the same as that of religious faith: ABSENCE OF REASON.
  
  
  
  
  
  

• found this through google. I'm also undecided. domain-driven sounds tempting but data-driven is simpler.
  
  regarding the link Jiang has posted, the author of the website is known as arrogant troll on c2.com wiki and slashdot. I'm not saying he is wrong in what he is saying but I wouldn't associate myself with him because of his reputation.