Wireless Phone Company domain model

[Samuel Rizzo]

Can't find any topic on this anywhere.

I'm having really hard times trying to understand it. Like some weird cardinalities.

Has someone got to understand it? Did someone feel the same?

Could I get any help about it here?

[Alessandro Gentile]

Hi Samuel
I have to face the same assignment and i feel the same way about this. The business domain model is skimpy and entities relationships are, at best, arguable....

[Teja Saab]

Most domain models in real life projects are complicated and esoteric. The domain models are created that way intentionally to force the candidate to architect a solution within the confines of the provided domain model.

[Alessandro Gentile]

Hi Teja
Thanks for your reply. After days of reflection I've drawn my conclusions. I think that Sun's business domain model is a coarse grained design (class diagram) of entities involved: there are only main entities depicted. I 'll try not to miss any requirement and relationships between them but my final design (class diagram) will be a little more complex than the Sun's one. The DB structure, too will be a little different. I'll try too not to add somethings that is not specifically required. Please tell me if i'm wrong!!! Any suggestion will be greatly appreciated....

[Teja Saab]

Alessandro Gentile wrote:Hi Teja
Thanks for your reply. After days of reflection I've drawn my conclusions. I think that Sun's business domain model is a coarse grained design (class diagram) of entities involved: there are only main entities depicted. I 'll try not to miss any requirement and relationships between them but my final design (class diagram) will be a little more complex than the Sun's one. The DB structure, too will be a little different. I'll try too not to add somethings that is not specifically required. Please tell me if i'm wrong!!! Any suggestion will be greatly appreciated....

Hi Alessandro,

The key is to ensure that the entity relationships within the supplied domain model are preserved. If you can come up with a design that preserves this relationship, but is much more flexible, I think you should be okay. However, changing the domain model generally is done in consultation with the business analyst and the architect may not and probably should not change the domain model to ease architectural challenges.
One of the recent posts on the forum indicated that a rancher failed the SCEA since he changed the domain model in his submission. IMHO, changing the domain model generally has significant impact on the business functionality and is best left to the business analysts. I did not change the domain model in my submission and created an architecture that preserved the supplied relationship. Since you can make an assumption about any vague aspects of the domain model, I would suggest doing so, but retaining the originally supplied entity relationships.

[Alessandro Gentile]

Thanks for your advice Teja, you helped clearing my mind

[Samuel Rizzo]

Hi Alessandro,

I tried to stick with the domain model. I did change many of the cardinalities though, till I ended up with something that made sense to me. I passed.

My advise is that you don't try to work with something you can't really understand. Make your assumptions. Document.

Focus on the final solution.

[Alessandro Gentile]

Hi Samuel,
I'm so happy to hear from you. Tonight i couldn't sleep thinking about the one-to-many relationship between minutes/data/texts and MonthlyUsage. My assumption is that a MonthlyUsage is an aggregation of consumption events (data, minutes, texts). This assumption is not based on any technology, it's just common sense. Thanks a lot for your reply, you really helped me.

[Vijaykumar Dixit]

Alessandro Gentile wrote:Hi Samuel,
My assumption is that a MonthlyUsage is an aggregation of consumption events (data, minutes, texts). This assumption is not based on any technology, it's just common sense.

I have made the same assumption and slightly updated physical domain model. I will let you know if I pass ;)

[Frank Jones]

I'm a bit confused about the 'Meter' Object, why is this in the domain model? Isn't the meter just a service? What sort of information would you want to store in a meter object?

[Janez Novak]

Frank Jones wrote:I'm a bit confused about the 'Meter' Object, why is this in the domain model? Isn't the meter just a service? What sort of information would you want to store in a meter object?

Here are my thoughts:
- Meter is part of the domain model because it contains business logic related to solve domain problem
- I see Meter as an interface to the service that you are talking about


Best regards,
Janez

[shekar hari]

Guys, I also got Wireless phone company assignment. I was very confused with the Domain model given by Oracle/Sun for WPC.

After seeing all your comments/thought, I am little bit confident now.

I was assuming MonthlyUsage as a Mediator Interface between MonthlyBill and Minutes/Data/TextMessages?

Thanks for sharing your thoughts.

[Vijaykumar Dixit]

Vijaykumar Dixit wrote:

Alessandro Gentile wrote:Hi Samuel,
My assumption is that a MonthlyUsage is an aggregation of consumption events (data, minutes, texts). This assumption is not based on any technology, it's just common sense.

I have made the same assumption and slightly updated physical domain model. I will let you know if I pass ;)

Folks I passed in Oct2011 with WPC. I did make subtle changes to domain model but made appropriate assumptions and documented them as well as the changes. Don't worry this is what an architect faces in reality.

[Frank Jones]

Vijaykumar Dixit wrote:

Vijaykumar Dixit wrote:

Alessandro Gentile wrote:Hi Samuel,
My assumption is that a MonthlyUsage is an aggregation of consumption events (data, minutes, texts). This assumption is not based on any technology, it's just common sense.

I have made the same assumption and slightly updated physical domain model. I will let you know if I pass ;)

Folks I passed in Oct2011 with WPC. I did make subtle changes to domain model but made appropriate assumptions and documented them as well as the changes. Don't worry this is what an architect faces in reality.

Just to agree with this, I also made a couple of minor (documented) changes as I didn't think it entirely made sense either, and passed with a relatively high mark. So don't be scared to modify things slightly to make them into a workable solution.