Problem is thinking in terms of data needs will create communication failure. As you put it, first figure out the data needs and perform the domain design. That brings me to next pointĭomain Driven Design is a more reverse thought process. Experience developers will notice patterns and in next iteration, we will refactor the 20%. Now back to real world, we get the 20% right in the sense they deliver the business value but are written in procedural style hard-coded in the front end. Fact that you all parts are complete and you get the mechanism wrong would result in system failure. Rest 20% is like collaboration mechanism that integrates all the parts of plane and help you fly the plane and reach the destination. But left 20% is too important to left open to communication failure. You win the 80 percent battle if you have these ready with Database design. Nothing more make sense to Business User more than Mock ups, Screen Shots or prototype. Rest of 20% is too important to left open to risks of communication failure Domain Design and Database Design could be parallel activities in some organizations) will not only help achieve 100% but is also cost effective for project with multiple releases. My argument is Mock ups, Domain Design and Database Design (in that order. I agree 100% with you that if you have a short term project with no future releases, data driven design is more efficient. Mocks ups, Screen Design and database will help to achieve completion of 80 percent of system. Survic has very nicely argued that database storage and retrieval is 80% ( I would say 70%) portion of application.
0 kommentar(er)
