E-commerce Domain Model Feedback

问题:

I've been working on putting together a rough conceptual model of an E-commerce website that basically allows users to resell concert tickets. It's purely conceptual and not something i'm actually making!

Anyway I've put together a domain model and I was hoping for some feedback. I've made class model before and modelled databases but found it quite difficult differentiating between them.

I've seen the words rich and anaemic thrown around a lot and I believe my model is anaemic. Would simply notating more behaviour make it rich?

Are my relationships correct? Have I correctly used my aggregations and compositions?

I would love any suggestions on improvements.

Thanks in advance.

回答1:

You have the right idea, but some of the UML is incorrect and a (business) domain model shouldn't have a User.

Some examples of problems I see:

• A User is probably not a Bidder and a Seller; rather, a User can play a Role of Bidder or Seller.
• Generalizations do not have multiplicities.
• It makes no sense to me for a Ticket to HAVE an Artist. A Ticket generally allows a Person to be admitted into a Show, and an Artist performs at a Show.
• Compositions can have at most one composing class.

I would remove compositions and aggregations from a conceptual model. Otherwise, I don't think it's anemic as a conceptual model. The next step would be to add behavior to it as an OOA model and generate some code from it. Please see Leon Starr's How to Build Articulate UML Models article for more help.

回答2:

As Jim says, you're not entirely clear on how composition and aggregation work. This example might be helpful. Tom Pender (author of "The UML Bible") uses it in his classes.

Suppose you have a car factory and you make cars. A car has an engine. In order to be a car, it has to have one; if you haven't put it in it isn't a car yet. But also, the engine is part of a car. The only reason to have the engine is to put it in the car. So, the engine has no identity or lifetime independently of the car. That's composition.

Now, suppose you have a junkyard. Same car, many years later. You can sell any items off the car and it will still be that car. If you sell the engine, the car will be the car without an engine. That's aggregation.

So, in a manufacturing context, a car is a composition of parts, and in a junkyard context, a car is an aggregation of parts. The point is that in composition, the lifetime of the parts is tied to the lifetime of the car, and in aggregation, it isn't.

Looking at your Ticket object, I would say that Venue and Artist are in a composition association with it. While the Venue and Artist certainly are not dependent on the ticket for their existence, you have to keep in mind the context. You're doing e-commerce. Your artist and your venue interact with the e-commerce system via tickets, and not in any other way. So composition. On the other hand, tickets are most certainly NOT composed of Orders. If that were so, there would be no such thing as an unordered ticket! So, tickets and orders have a simple association, not aggregation or composition.

As for your bidder and seller, they are users. So you have your inheritance arrows backwards. If Bidder and Seller have specialized user behavior that is independent of one another (e. g. "OfferBid" and "AcceptBid"), then they need to be modeled as specializations of the User class. If they do not, then they are just two users that are acting in different roles, and can be modeled as such.