Since nobody else seems to comment, I'll pitch my 1cent worth of 
opinion.

+1 on object oriented modeling differing from service oriented modeling.

That said, my comments on the article is as follows:
Figure 1 is suppose to be a class diagram, but the author is 
using "composition" in all relationship between classes when some 
should be just "aggregation". For example, a contract is not necessary 
to create an instance of a customer.
Furthermore, there seems to a confusion between domain modeling and 
implementation class design. In Java nowadays, systems may be developed 
using Spring with relationship between classes defined externally from 
a class.

H.Ozawa

--- In [email protected], JP Morgenthal 
<[EMAIL PROTECTED]> wrote:
>
> I'd be interested in other's opinions here, but it seems to me this  
> person is confusing a domain object model with SOA.
> __________________________________
> JP Morgenthal
> 


Reply via email to