Keep entities in 1 eSpace vs split entities into multiple eSpaces

Keep entities in 1 eSpace vs split entities into multiple eSpaces

  
Keep entities in 1 eSpace vs split entities into multiple eSpaces It would be interesting to hear your views: Why you've split them? or why you've kept all entities in one eSpace?
Robert, 

check out this presentation "The Art of Designing OutSystems Architectures" from the last NextStep 

here: http://www.outsystems.com/nextstep/presentations/

Cheers, 
Ricardo.
@Ricardo

Interesting!

With this type of design, how do you manage the look and feel? (themes) 




There is more information on themes, so here it suggest you store your common theme under "UXWidgets", but what about login page/logout page, error pages, roles?

In Slide "Common look and feel between applications" I propose to have an infrastructural component just to make public the common theme and page layouts. Composite applications sharing the same look and feel should then consume the common theme and page layouts

The reason why this is separated in a Infrastructural module it is to ensure reusability and granularity. If you expose the main theme and page layouts on one of your composite applications or on your Portal mashup, all other consuming applications will have to reference a huge eSpace, pulling a complex net of dependencies.
Francisco Menezes wrote:
 
Francisco

Let me clarify,

From the notes ...

Layer 4 – "UX Orchestration" are applications  


Layer 3 - "Composite Applications" are application modules specific to application on Level 4  

Layer 2 - "Core Business Services" are reusable stand alone solutions 

Layer 1 – "Infrastructure Services" are reusable stand alone solutions and/or connectors  to external systems.
 
 
So where should the theme be located? Level 1, So that Level 3 and Level 4 can use them. Should the menu also be located here? or in Level 4?