RE: Integration at user interface level or not?

Integration should be done according to the nature of functionalities, best described (other terminologies exist) by the MVC pattern:
 View: transient objects, no sharing.
 Model: persistent objects, shared.
 Control: transient objects, shared.
 Service can be added for instant shared access (no life-cycle). 
 http://caminao.wordpress.com/how-to-implement-symbolic-representations/architectures/ http://caminao.wordpress.com/how-to-implement-symbolic-representations/architectures/
 

 

---In [email protected], <mirko.sertic@...> wrote:

 Hi Mizra
  
 Yes, UI integration is a bad thing. In my example, there are in fact two different deployment units/applications, each of them providing or consuming a well defined set of public services(open host services in DDD lingo), and an ACL(anti corruption layer) on client side.
  
 The key question is how can we create something that might be called a "composite application". Using web technology, we could combine existing HTML frontends with some kind of portal technology, not portlets, of course, but perhaps some ESI(edge-side server includes) or scripting on client side by parsing HTML microdata, for instance. This kind of user interface composition is possible, but i still want to keep the two applications independent. This is tricky, as they must share common resources like css or scripting, for instance.
  
 Complex interaction scenarios are a different beast. Consider the following use case in the composite application: choose a product by invoking the product management system, and place an order for this product in the order management system. From my point of view, this scenario deserves its own bounded context, providing some domain services for sub-system service orchestration and and of course some kind of user interface.
  
 But one question still exists: might it be possible to use some kind of composite application architecture to create the behavior, or would it be the best to discard this idea as it would introduce to much complexity? I would drop the composite application idea, and create a complete new ui for the case, but what do other DDD practitioners think about this? Has anybody sucessfully used DDD with composite applications, or are they mutually exclusive from a designers point of view?
  
 Regards
 Mirko
  
  
   Gesendet: Freitag, 11. Oktober 2013 um 15:11 Uhr
 Von: mirza.abazovic@...
 An: [email protected]
 Betreff: [domaindrivendesign] RE: Integration at user interface level or not?
    
 Hi Mirko,
 IMHO integration at UI is no way to go. Don't let presentation layer or UI technology dictates how lower layers are designed (and leak in lower layers) after all UI is depending on lower layers not opposite.
    
 Context mapping might be the answer
 "Context Maps is as the source code implementations of the integrations"  Implementing Domain-Driven Design Vaughn Vernon excellent book.
  
 Other way is to use domain services (if You don't know where to put method or business rule on which of two-three aggregates or some value object put it in domain service)
  
 Or maybe You have some hidden shared kernel there (like product)
  
 I'm open for further discussion after all I might be (totally) wrong.
  
 Mirza
 
 
 ---In [email protected], <mirko.sertic@...> wrote:
   Hi@all
  
 I'd like to discuss the following scenario, probably we can get to something that can be considered as a "good or best practice".
  
 We have two bounded contexts, a product management bc and an order management bc. Product management offers services like "search for products", "change product price" and other stuff. Order management offers services like "place order", "cancel order", "ship order" and so on.
  
 Order and product management shall be deployed as separate deployment units, each of them with it`s own user interface. Now, there is a kind of portal, for instance a web shop, another ui, which offers a customer functionalities like "search for products" or "place order", hence it is a rich ui for the provided services from product and order management. So from this point of view it has its own user interface, tuned for web responsiveness for instance.
  
 Now, i think it is the best way to separate the user interface, and provide one for every user group and bounded context. So where would be a product management ui, a order management ui and also a webshop ui, and they consume or invoke a known set of application services.
  
 But how should common ui parts like a product search form be treatened? This functionality is required by the product management ui and at least in the webshop ui. From my point of view it wouln't be good to create a common search form and share the classes and ui logic accross multiple bc's, as this would introduce complexity in workflow control etc. Another problem would be to chose the right ui technology for form integration across different deployment units.
  
 So the key question is: Integration over application services vs. integration at user interface level? Portlet(bad) technology vs. plain html forms for instance? Common classes vs. redundancy and indepencence and encapsulation.
  
 Any ideas about this?
  
 Thanks in advance
 Mirko