Thursday, July 17, 2008 11:42 PM Sean Feldman

Data Driven Or Domain Driven Application?

The company I work for has a significant amount of web applications of a specific line of business. This line of applications started 8 years ago (I am with the company just for the last 3 only). Since I started to be interested in Domain Driven Design, felt strongly that this line of applications should be re-addressed with a DDD approach. But the resistance was enormous, motivating that "these are the pure data centric applications and there's no place for domain, the data is the domain and as a result of that it is a DATA driven design application".

I disagree.

Why do I disagree? Here's the theory I have that might be applicable not only to this case.

As a company that started web development 8 years ago under Microsoft wing, the natural choice for developers was classic ASP and SQL Server. With or without DDD, the business these applications were intended for had it's behaviour, rules, entities. Now with something like VB Script in classic ASP I cannot imagine proper tool for DDD, and on the other side, database was there to enforce the feeling of key components of design in shape and form of tables (Users, Selections, Benefits, etc.) So DB was a natural selection to grow the domain design, and incorporate some of the business logic (default values, calculations, etc).

Today, when we moved to C# and have a solid language to support good object oriented practices, database gets a role it should have had from the beginning -  persistence medium of the domain objects state. No logic, no design driving power, nothing of that.

How I can be sure about the theory? Over the years I see how painful the maintenance becomes, what challenges our developers face when they need refractor code, how non-trivial it occurs to do a trivial feature addition. The biggest from my point of view, is the fact that looking into the code, you cannot understand the business (behaviour, rules, logic).

This is why I believe those so called "data driven applications" should be reviewed closer, some of them are really "domain driven applications" not expressed well due to the luck of the proper tools at the time of creation.

Question. Doubt. Don't accept just because it's widely accepted.

Filed under:

Comments

# re: Data Driven Or Domain Driven Application?

Wednesday, August 20, 2008 4:31 PM by jiang tang

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 .

# re: Data Driven Or Domain Driven Application?

Wednesday, August 20, 2008 11:20 PM by Sean Feldman

@jiang,

First let me thank you for such a passionate comment. It is OK to disagree with whatever I write.  From your words I sense lots of disappointment from DDD. Let me try to answer what you have implicitly asked in your comment.

Games or real world subjects – doesn’t matter. You are absolutely correct about the fact that data is the blood of the businesses.  Unfortunately,  I absolutely cannot agree with the statement of yours saying that object is a data container. Object has behavior and data is its’ state at any given moment.  Database is used to persist  the state. In an ideal world, where memory is limitless and power never goes off, you would have the state living in memory and would not even have to persist state into the database.  But this is not the point. An employee, from the sample you brought, is an entity. It does have its’ own behavior in different contexts.  The behavior depends on the domain employee is associated with.

Pain of understanding logic spread everywhere is a result of poor code, not DDD being applied. Without DDD a poorly written code is not maintainable either. Databases are good for storing the state and I am not arguing about that, it’s just not a good place (way) to capture, express, and maintain logic. 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? Or how an email field in user record will validate itself and send email for notification? These are object behaviors you cannot embed in pure data. I have seen logic buried inside stored procedures and triggers – painful. We (myself) are developers first, and code is what we understand better. Refactoring with automated tools and unit testing are not applicable to stored procedures and raw sql.

You mentioned that “When you do DDD, you are one layer removed from the real business”. On contrary, you are getting closer to business by introducing a layer of ‘abstraction’ over the data. You are closer to understanding the business behaviors and processes, capturing it in the code. Database will reflect that capture of knowledge as well id a slightly different way – by capturing the structure of the state. The most critical thing is to be able to understand what drives the whole thing, and not what the data snapshots are only. Success, if you ask me,  is in capturing the behavior in code and state in database.

# re: Data Driven Or Domain Driven Application?

Thursday, August 28, 2008 10:28 AM by jiang tang

"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.

# re: Data Driven Or Domain Driven Application?

Thursday, August 28, 2008 11:18 AM by jiang tang

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.  

# re: Data Driven Or Domain Driven Application?

Tuesday, September 02, 2008 11:30 PM by Sean Feldman

@jiang,

I will not keep arguing about something we don't see in the same light, sort of useless. The same way you see the logic being stored in sprocs and nowhere else, I dislike the idea of doing it, just for a few reasons you would consider quiet kosher. I have learned to have respect to others that not only argue their point of view, but also can parove that its working. If yours is the case - great. Next is to show others how to solve it successfully as well. So far I have witnessed lots of pain caused by the fact that logic was in the DB and not in the natural environment - code. Even that address example is kind of funny. I live in Canada, postal code is an encrypted physical location of your address. With code I can validate if the provided address is matching the postal code. I can unit test it, that will be my de-facto documentation, other developers can understand that logic and carry on. With sql-is, well, it's just not there. So the reality for myself - DDD is a better alternative. Do I know how to do it the best way - nope. That's something I am learning. Is DB way to do it? Some solutions will require, but those that are logic and behaviour - I doubt.

I honestly thank you for sharing your ideas. Would be interested to see some of your posts where you could show and compare Data driven approach taking prizes over the DDD.

Sean

# re: Data Driven Or Domain Driven Application?

Sunday, September 14, 2008 1:26 PM by Wilfred Chan

hi Sean, Jiang,

i'm also suffering in this issue. At the moment, i'm managing a project to re-code a Delphi 3.0 apps into Java (Window based). As i'm new to this business, i rely on the other 2 teammates who have been in-charging this project for few yrs.

In the 1st meeting, they shown me an ER and a Use-case diagram. And suggesting all business logic should be in StoreProc. Then I insisted to use DDD approach first.  I then realized that the application has simple business functions on the User Interface layer.

The functions mainly are enquiry and reports. When there is an "update", it updates some fields in 10k of rows in the DB. And almost tables are coming from external sources.  That it seems Oracle loader is the only way because using Java to insert 10K of rows would take a long time and take extra effort to develop.  Therefore, some business logic will be embeded in the loader script.

Now, i'm struggling to make a decision that whether DDD approach is appropriate or not.  Could you please give me some advices.

# re: Data Driven Or Domain Driven Application?

Sunday, September 14, 2008 4:24 PM by Sean Feldman

@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.

# re: Data Driven Or Domain Driven Application?

Wednesday, September 17, 2008 1:56 PM by Wilfred Chan

@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

# re: Data Driven Or Domain Driven Application?

Wednesday, September 17, 2008 11:31 PM by Sean Feldman

@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

# re: Data Driven Or Domain Driven Application?

Monday, May 11, 2009 4:03 PM by Jiang

I have been looking for a more intelligent commentator to debunk all the perceived fallacies in transforming GUI type OOP into Data Centric OOP and the ever worsening trend of making simple things unnecessarily complex for the sake of making it more complex.  People are duplicating what database/ER modeling are already doing and doing all the busy-work that adds no real value to our customers who pay our bills and don't care a hoot about how many layers of code you can add to a simple table/form display.  

Here I think I finally found an ally who totally debunked the myth of all-things-OOP.

www.geocities.com/.../oopbad.htm

# re: Data Driven Or Domain Driven Application?

Monday, May 11, 2009 4:15 PM by Sean Feldman

@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 :)

# re: Data Driven Or Domain Driven Application?

Monday, May 11, 2009 10:12 PM by Terry Thibodeau

@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.

# DD vs. DD – The End

Monday, May 11, 2009 11:14 PM by sfeldman.NET

I had an old post , back in July 2008, where I had a few comments on Data Driven vs. Domain Driven applications

# re: Data Driven Or Domain Driven Application?

Friday, January 22, 2010 7:09 AM by lubos

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.