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