Komandir Kozlov wrote:Guys, who are working on this assignment or already has finished it and all others. After reading requirements ten times I still don't see any need for use of DB here from provided use cases. Is it possible? I mean that application will be kind of 'not production' w/o DB, but anyway as I understand we need only to complete supplied requirements and not to try to imagine other scenarios. I understand that we can point this in list of assumptions bla bla bla, but still need your view on this.
To make clear that I am not asking for concrete advice for implementation (which is of course prohibited), I just wondering if it is possible at all, as I don't want to loose points only because I didn't make all assumptions (and assumptions can be made recursively ad infinitum ) etc.
SCJP, SCWCD, SCBCD, SCEA (1)
Komandir Kozlov wrote:Hi Rumen,
Thanks for your reply. But both your examples seem not very convincing for me. User accounting? Why do you think we should implement it even if we haven't been requested to? There are a lot of e-commerce sites which allow you to make full buying cycle without logging in. Moreover, I am sure that accounting is such functionality which couldn't be missed by our business analyst if was required. Regarding second example, it seems to me questionable to save shopping cart between sessions even with accounting. Most real-life ecommerces don't do this. Again, you are trying to mind up new use case - Shopping cart saving, but we wasn't required to do this!!!
I understand your point, but with the same success we can mind up many more use cases, which wasn't required. Where is the border line???
Just to mention, the shopping process in real life is asynchronous and long-time consuming, definitely longer than a single web session. Think about sending mail with receipt, confirmation mail, report mail for shipping progress, promotion emails, credit card fraud detection, etc. Often the exact payment processing is taking more than one day for fraud prevention reasons and so on and so on
It's up to you where you'd put the border line, that's why there is assumptions section, hence if you decide no DB, it won't be mistake, but this might open questions about reliability (check about ACID) IMHO.
I designed my architecture with DB because the system won't be reliable enough if doesn't store transaction, user and order information.
J J Wright wrote:Where does your product catalog come from?
J J Wright wrote:Does your check-out use case include a step for entering a shipping address? If no, then where does it come from?
Where does your product catalog come from?
Not only this - almost all information in modern web sites is dynamic, therefore configuration/customization is an essential feature leading to logical decision to store this data in DB, but I should admit that he is right that nowhere has been mentioned this in use cases, neither system requirements, so in sake of theory I think he could provide design without DB and still pass the test. It even might be explicitly mentioned in assumption section.
It's possible to implement a system without DB. but you have to have some sort of data repository such as system files. For example, you need provide shipping method selections and credit card type selections. such selection information should come from business tier other than harcoded in your jsp files.
Although you can argue about that here but there are some best practices in this field. The assignment has an availability requirement. such availability means many things not just mean your web site is still running.
Yes, I don't see any problems to have section for shipping address in check-out page along with payment info etc.
J J Wright wrote:
Are you saying your requirements explicitly include an "enter shipping address" step in the main flow of the check-out use case? Or are you saying, I don't see a problem with adding my own steps in order to fit my design? I'd be very cautious if it's the latter.
Leave the business decisions to the domain experts.
I don't understand your point here
J J Wright wrote:This thread might help
It makes a lot of sense for me to use generic ProductCategory instead of those 3, but is it allowed, as in assignment it is stated that objects on domain model are key objects and should be addresed in our design?