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?

One thought on “Database-driven design vs domain-driven design

  1. It’s not my preferred way but I think it is possible to make an estimate based on a database design. A database model alone isn’t enough, at least a (rough) description of the required functionality has to be available also. I have seen estimates based on this information that in the end seems relatively accurate. Based on the complete functional requirements it is possible to estimate the cost including making a detailed design.

    In this case however making an estimate for a fixed priced project based on preliminary analysis phase sounds very risky! In my opinion it is very likely that the estimate will not cover the actual resources needed. Functionality will probably change in the coming time and is not covered by the estimates you’re doing now.

    I think a RFP for a fixed-price project based on incomplete requirements is not preferable. If I was responsible for answering this RFP I might have tried to convince the customer of this. This means, not you refusing to make the estimate but the managers responsible for this RFP talking to the customer.

    To cover the risk involved in this you will probably see your estimate multiplied by a factor, after that a lot of overhead costs are added to the outcome of that and to be really ,really sure you will not lose money on this RFP an extra amount is added to the semi total. Resulting in a fixed price that might be too high which of course minimizes the change the customer agrees with your proposal.

    Maybe it is better to wait for the customer to finish his analysis phase and base a fixed price proposal on that. But hey, most of the time that isn’t the decision of the people responsible for making the estimate 🙂

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *