You are within the rules for talking about the assignment. Congrats on part 1 and welcome to CodeRanch!
I've looked through the domain model the use cases but it just doesn't seem right to me. I would have to 'correct' the use case and domain model but I'm not sure its open to interpretation.
That's a matter of debate. Some people say the are penalties for changing the uses cases. (I suspect this is because it could be oversimplified.) Others say it is fine. Personally, I wouldn't change the use cases unless they contradict each other. I would make assumptions about the details and document all of them.
One actor in the use case specifically mentions an employee. But there is also an actor called 'Buyer'. The way I've interpreted the problem is the employee is the Buyer in my system.
I haven't seen the assignment so I don't know for sure. But couldn't a buyer be external too? Duplication isn't necessarily bad and is something you can design for.
My solution doesn't seem very complicated. I alway try to simplify solutions in real life but I wonder if I'm missing the point of the exercise.
My solution didn't seem complicated either. I think that's because I'm used to complex real world systems. There are some posts in this forum with how many classes/components/etc were in a solution. (See my signature for a blog post containing my metrics.) This should give you a feel for whether your solution is too simple.
The domain model has items that I don't think are relevant.
I only encountered one odd element in my domain model and assumed it was important.
Should I take the use case literally 100% (I know in real life I would go back to the customer).
Not 100%, but not 50% either
. And yes,
you should document all assumptions. One thing I did on mine was write that I assumed I asked the customer to improve the use cases in certain ways and he said no. That way I showed my analysis skills in noticing things that could be better without changing the spirit of the assignment.