I think however on the DDD point that he made he only gave the Microsoft point of view with Data Driven design. Microsoft has been heavily focused for the past decade on building applications that are basically CRUD applications. I have always been against this type of approach because you might as well expose an Access client or SQL Server client to the user. However I know there are benefits to this approach - fast to get off the ground, a lot of Microsoft technology support for it and most junior to mid level developers will understand it (small learning curve).
Miguel notes that Data Driven applications are faster to get started with than DDD and for most clients all they want is to get their solution out the door as fast as possible. As a person that would like to work in a field, which we would like to call Software Engineering, I have a big problem with this.
As soon as you build an application for a client you are building an application that has one or many competitive advantages over other competitors. That model should be built according to the business's ubiquitous language. The main reason for this (and Miiguel failed to mention this) is that although it may take a longer to start the project, it has huge return on investment on the later parts of the project. Any second, third, or nth iteration you will start seeing the benefits of your initial investment because your design is modeled according to the business model. It is easier to express the business processes in code accordingly. The only reason you would have to do major rewrites is if the business's model changes (which is a strategic shift it direction).
Software is a craft and should be spoken about passionately. I do not mean to rant and rave but while I believe most technologies and designs have their place I do not want developers to default to the Data Driven design because it is an easier paradigm. We are software engineers and have an ethical obligation to the client and business to build systems which is catered to their needs and model their business process to help expose their competitive advantages. We know how to build systems and which way is the correct way. It is our duty to advise them and not the other way around.
Any questions on DDD don't hesitate to contact me.
Good books to get started with DDD:
- Applying Domain Driven Design by Jimmy Nilson
- Domain Driven Design by Eric Evans (the original :))
- Domain Driven Design Quickly (located on InfoQ)

No comments:
Post a Comment