Reputation: 1007
How do you differentiate between design decisions versus implementation decisions ?
To give a specific example: We are developing some web services which will integrate our application with another One of the question I asked was- do we want the integration between the two applications to by asynch or sync ?
Someone suggested that its an implemntation question and not a design.
My plea is- if I change something and you do not need to know what or why I changed- it's implementation decision.
However, if I change something- which changes how you use my services- its a design decision.
If I change my implementation to asynch from synch- I guess it is going to affect how the services are consumed- hence- its a design decision and not implementation
e.g Whether I choose XML for storage or Database- as long as it doesn't affect the other application- it remains an implementation choice rather than design
Do you agree? disagree? thoughts ?
Upvotes: 2
Views: 213
Reputation: 96806
Design phase comes before the implementation phase (at the front-end of the project). Of course, you can change the design once you have started implementation if there is a good reason: this is why there an "iterative process"
product requirements -> design -> implementation -> back to product etc.
in order to converge to a product.
The Design phase exists to optimize (read: $) the implementation phase and make sure that the business objectives are met.
An architecture is yet another term that is often associated with design: during the design phase, an architecture is chosen.
Upvotes: 2
Reputation: 38364
Retrieving results and errors from an async interface will be significantly more complex, but will have the obvious benefits particularly in terms of perceived performance and flexibility. Since you have to weigh the overall pros and cons of each approach and how they meet the requirements of your application, then I would say it's a design decision.
Upvotes: 0
Reputation: 80829
I think you already know the answer, and to be honest it is a bit of an unnecessary semantic distinction for most practical purposes. Having said that, it's design if it impacts the end user / consumer, it's implementation if it doesn't. In your example it will have a profound effect on the design of any client consuming your services, so it is certainly design.
And there is no sequence. You cannot realistically complete design before implementation starts and slavishly following a design which has a high and unnecessary implementation cost is very dangerous. You may choose to redesign half way through implementation given what you have learnt about costs.
Upvotes: 5
Reputation: 2674
To me, a Design Decision would be whether or not to support Async and Sync or just Sync communications in this case. The Implementation Decision would be how to implement support for the Async or Sync communications.
Upvotes: 2
Reputation: 7297
My favourite definition of architecture:
Architecture is the set of decisions that are hard to change
I think that holds for the design/implementation divide as well. If a decision is sufficiently hard then it's a design decision.
The definition of "hard" is somewhat subjective and depends on your project. I would say that the sync/async decision in your question would be difficult to change later on - so I would call it a design decision.
Upvotes: 2
Reputation: 328754
I'd argue that a design decision is what you want. It's your ultimate, untainted goal.
An implementation decision is when you have to adjust your desired design because of some technical problem.
Upvotes: 0