On Wed, Nov 19, 2008 at 20:10, Arif Rachim <[EMAIL PROTECTED]> wrote:
> Why not fit ? If I have an application need to connect to a bank, this
> bank configurable so I create bank entity and add functionalities to
> transfer one account to another, perfectly make sense
Chances are each bank requires different kind of integration. They
might even have different web services, different type of object need
to be instantiated, etcs.
It would be very weird if we start creating MayBank implements Bank,
Citibank implements Bank and we're forced to implement all bank domain
methods that your customer doesn't have service agreement with.
> I don't believe service should be stateless, it sounds very much like
> .... dogma. Service should be singleton or application scope is
> reasonable. Anything can be service now, my Bank object can be service
> too. i just need to annotate the transfer method to @WebService then
> it become a service already.
Err. The moment you put @WebService on a method. Don't the method
arguments and the returned values has to follow web services
requirement.
E.g. Serializable etcs. For example,
TransferReceipt Bank#transfer( Money amount, Account acc );
Doesn't TransferReceipt, Money and Account would need to be "value" object.
Just assume if these are domain model.
Account#accountDetail()
AccountDetail#customer()
Customer#mailAddress()
I don't think it makes sense for all these objects to be exposed to
Web service either.
Hence, You would probably create another WebService layer, where it
interacts with Application/Domain layer.
>> That's not it. In DDD, just to summarize the first paragraph:
>> The domain operations just doesn't fit naturally to an Entity or Value
>> Object.
>
> What paragraph are we referring to ??
The first paragraph of the Services page I pasted before.
> This is where it started, I do believe todays application should
> eliminate layers. Application Layer, and Service layer are created bec
> people still think, all the domain should clean and does not contain
> any layers integration. Its true, and it will remain true. However now
> we have a framework to communicate with the layer, so we dont bother
> how we interact with the layer, instead we focus on our DDD.
The main issue is Layer/Module in most applications are not enforced.
Hence, roles and responsibilities of application can easily be broken.
I'm not sure if seam or webbeans has this concept, but QI4j definitely
have it :).
In Qi4j, if entity has only module visibility, other module/layer
would not be able to create it.
if it has a layer visibility, other layer would not be able to create it.
If it has an application visibility, only other layer that uses the
layer can create it.
This applies for entity, composites, services.
> I disagree with that :) There is no direct connection between DDD and
> the easiness maintaining the application. Does it means spring app
> which is not using DDD will be more easy to maintain ?? :)
Err, shouldn't the question be. If a DDD app doesn't use spring will
be easy to maintain.
The answe rwould be yes.
> I believe lesser code will produce lesser bug, I believe framework can
> help us. I believe anemic objects are dumb.
Lesser code doesn't mean lesser bug. If it's not modeled right at the
beginning. Adding feature
would be an uphill battle. If each feature are not isolated right, the
impact of adding a feature might
requires wide changes in the application etcs. That to me a PITA.
> Offcourse you can :) you can map username and password to the webform.
> That is the point what im talking about. That is the difference
> between webbeans and others :) No more Value Object.
No no. You didn't answer my question.
If we have domain model like this.
interface User
{
String userName();
Password password();
interface Password
{
boolean authenticate( String password );
}
interface AuthenticationService
{
void changePassword( User user, String password );
}
I fail to see how webbeans/Seam would be able to even do
change password or authenticate form without requiring a value object.
To me. It doesn't make sense to expose password as String from user model.
Although Password model itself doesn't make any sense either, I would
actually add
AuthenticationService#authenticate( User user, String password ) method.
To be honest, after thinking more about it. I would ended up creating
a lot of ValueObject for UI,
because chances are domain model will not map nicely with web forms.
Nor does it make sense to make
domain model to be serializable.
Regards,
Edward Yakop
