“I agree with you about the size of projects; but deep in my heart, I also believe that all larger business projects can be split into smaller projects, so, I do not believe “TDD with mocks and DDD without data” is good for anything -- I will keep an open mind though”
Thanks for pointing to Scott W. Ambler.’s book ‘The Object Primer’. It helped me to write this post. That is what I wanted to articulate in first place
First thing nobody is underestimating the importance of Data in Domain Driven Design. But there are following problems or realities in Enterprise Data Design (Scott calls Legacy Database design but DBAs continue to employ for consistency purpose)
1. A single data field is use for several purposes.
2. The purpose of a data field is determined by the value of one or more other columns.
3. Inconsistent values are stored in a single data field.
4. There is inconsistent/incorrect data formatting within a column
5. Some data values are missing with in a data field
6. One or more data fields that require do not exist.
7. Additional data fields that your application will need to support if it uses the legacy data exist
8. Multiple source exist for the same data and it is not clear which one to use
9. Important entities, attributes and relationship are hidden and floating in text fields
10. Data values can stray from their field descriptions and business rules.
11. Various key strategies are used to identify the same type of entity
12. You require a relationship between data records that is not supported by legacy data.
13. One attribute is stored in several fields.
14. Special characters within a data field are inconsistently used.
15. Different data types are used for similar columns.
16. The legacy data do not contain sufficient detail.
17. The legacy data contain too much data.
18. The legacy data are read-only, yet you require update access.
19. The timeliness of data varies from what you require
20. The default value used by a legacy application does not reflect the default value required by your system.
21. Different representations of the data exist.
22. The naming conventions used are difficult to understand
As per my experience with DBAs in past,Some decisions may be right in their own way. They are more concerned about efficient storage of data; need to be consistent with existing databases (what Scott calls legacy) and future extensibility at data storage level.
Some of above factors limit the database design diagram to be used as effective communication tool with all stakeholders. We need a abstraction above database which hide these complexities and communicate more clearly Problem Domain/System Blueprints to users.
This is where come entity classes’ diagrams (Since we both agree on importance of process classes diagrams, activity diagrams, Sequence diagrams etc.) which can hide all above mentioned storage details from system users. It will help the programmer to nail down the requirement and prepare the blueprints with out waiting for database design to be over. Once requirements are completely nailed, data storage/retrieval is more implementation details.
This debate is similar to XML Hell debate. Nobody is arguing against the importance of XML but we need an abstraction/Graphical tools to hide its rawness as discussed in the following mail
The Object Primer – By Scott W. Ambler
I was recently debugging Web Site functionality issue with a client. We were not able to reproduce the issues at our end. I saw that the c...
Survic has very nicely argued that database storage and retrieval is 80% ( I would say 70%) portion of application. Mocks ups, Screen Desig...
Petshop Architecture 4.0 I have used earlier Petshop Architecture. It left a mixed feeling. It was simple to start with but not extensible...
Architecture - client requires at least rudimentary skills in these areas. What is SOA? Benefits? SOA principles for WS? Name standard arc...