> 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.
There are two items in this paragraph : 1. Integration 2. Functionality For the integration part eg what technology to use, or what kind of we service need to call is not part of the business logic part. However the functionality regarding business logic eg service agreement between customer and bank should cater by the domain. I would put it as this way, I should have entity called Bank, i should have another entity to maintain BankCustomerServiceAgreement. So what ever logical functionalities with respect to customer and bank service agreement, I will put it inside this method named bank.transfer(accountA,accountB). Now how do we integrate our bank transfer method with the upstream bank interface itself is a different story. We can achieve this in many ways. eg : in bank.transfer(accountA,accountB) based on the bank object state (say MayBank or Citibank) we can fire a message into messaging system, and let messaging route to the destination bank. In nut shell, let the logic regarding service agreement handled by the domain bank based on the bank object state (eg Citibank or Maybank), and let the integration either using tcp stream, or webservice, or even flatfile handled by another endpoint system. > 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. Definately we can put some restriction, either you want to expose or not is up to you. The point is, we still have the control for what we want. > 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 Though its almost one year since first time i heard Qi4j, still not very familiar. frankly speaking, I fail to see how Qi4j can reduce boiler plate code, and bring easiness in development. I haven't seen any decent documentation or sample program developed using Qi4j ? When can we have QPetStore ?? or QPetClinic ?? or QaveatEmptor ?? version ?? Cheers !
