I was listening to a great HerdingCode podcast by Greg Young. He discusses how modern software is failing us. He says that these days we base our success on past failures.
He goes on to talk about how modern software has evolved to become a basic CRUD (Create/Read/Update/Delete) system. He proposes that if this is the type of systems we require then we might as well create an add-on for Enterprise Manager for SQL Server and let the users work directly on the tables. Sort of what Access gave us....
He argues that our software should not consist of how to store data but rather on the behavior that the client needs. A great example of the difference between CRUD system and DDD system:
A DDD person will chat to a domain expert on what the requirements are. The domain expert will reply that he needs the system to update an employee's salary. Greg Young argues that this is the wrong approach. We have trained clients over the years to speak in CRUD. What we should ask is what is the behavior associated with the salary increase? Did the employee get a promotion? Did the employee transfer between departments? Did the employee get a pay increase? All of these options have different rules associated with it.
So as a software engineer we should understand what the business requires and model of software according to that. Doing so we will avoid pit falls and make our software more descriptive and re-usable. We should not just tackle the domain logic with this approach but the UI as well. Design screens around tasks and not CRUD operations.
Some very nice things to think about. Check out the podcast, it could help you...
Subscribe to:
Post Comments (Atom)

Interesting podcast indeed! I grew up in the CRUD generation, so I know exactly what Greg means, but I'm a little uncertain how to go about design differently.
ReplyDelete