Fri, Jul 1 2005 12:00 AM
Erwyn van der Meer
Database-driven design vs domain-driven design
Today I had to come up with a cost estimate for a Request For Proposal (RFP) for a fixed-price project. The customer asks for it to be developed using a waterfall approach: Analysis; Design; Coding; Testing; Integration; Maintenance. Estimating the total cost seemed to be very risky to me, given that only a preliminary form of the Analysis stage has been completed by the customer. So I had to do a mini design phase in my head. Including imagining some User Interface for the application.
I am a bit embarrassed to admit I had to resort to estimating using a database-driven design for this project. I really prefer domain-driven design. But there wasn't enough time to design a full-blown domain model. Glimmers of a data model could be captured from the requirements put forward in the RFP. Ideally I think it should have been a mix. A large part of the application consists of just very straightforward CRUD operations for several entities with simple relations. Database-driven design can be a very appropriate approach for this.
The other part of the application is some kind of workflow with extensive business logic that performs elaborate checks and balances. For that part I would like to start with designing a domain model instead of data tables, but the RFP leaned heavily towards a data model. Another thing that hampered me was my incomplete understanding of the domain at hand.
What do you think? Is it possible to give an estimate for the cost without completing a detailed design phase or should I just have refused to do it? What approach would you use?
Filed under: Architecture and Design, Work