I am under impression that, if something is not right or not clear in domain model after reading it several time, then few assumptions can be made and solution can be based on that. If any one wants to comment on that or have some other thought ?
Here are my 2 cents on this.
While we can make any assumptions we want in part 2, we need to ensure that those
assumptions are reasonable. In other words, we cannot make an assumption that makes it very easy for us to architect a solution. Needless to say, the business domain model is provided that way to
test how we can architect a solution for a complex problem. Even in real life, the business model is generally created by a business analyst who doesn't care much about the technical implementation of the solution. We cannot go back and ask the business analyst to change the model to make it easy for us to architect a solution.
I think the key in part 2 is to architect a solution that solves the business problem and addresses all of the business and non functional requirements. If you need to change the business model for any reason, make sure that by changing the model, you are still meeting all of the original business requirements. In other words, the only reason to change the business model is to address any ambiguity. However, if your changed model is in a way a superset of the originally provided model, it should be okay. For example, if the provided model allows you to have one credit card per customer and you change it so that a customer can have multiple credit
cards, you are not really breaking any requirement. You are only making the system more flexible. However, changing the core business object relationship itself just to make architecture easier is a big no IMHO.
SCEA 5, SCJD,SCWCD,SCJP,PMP,IBM-SOA Solution designer,IBM-XML