I am designing an application for a client but I am not sure if the architecture will be able to support gracefully his future demands for container-based deployment in a private cloud (docker on Amazon). 

Here is a draft of the architecture so far. 

  • Enduser - Reactive Web Module for the View.
  • Core Services -  Service Modules containing Entities and Business Rules for its own business domain. Will consume Integration Services Modules and provide them to the view Module through Service Actions.
  • Foundation Services  - Integration Services responsible for consuming external REST services providing them to the Core Services through Service Actions. There will be no dependency between the Integration Services and the Enduser module.

Additional information:

For now, each Integration Service Module will only be consumed by one Core Service Module, but in the future, they might be consumed by Multiple Core Services through Service Actions.

The Core Services will probably be consumed by other applications int the future.

Some Questions:

  • If I want to expose the services consumed by my Integration Services to multiple modules, should the dependencies be between the Core Service for that business domain and the other Core Service modules or should I allow my Integration Services to be consumed by other Core Services rather than the ones responsible for that business domain?
  • Will this architecture be able to support my clients future demands for container-based deployment in a private cloud gracefully?
  • Will this solution scale without problems?


Thank you all, any opinions will be appreciated.

Hi Swatantra Kumar, 

Thanks very much for your response. I already had gone through the articles and could not find the answers to my questions, that´s why I posted here. 

I am not sure I am asking for an Architecture Review, but if I am, isn´t the purpose of the forum to share knowledge? 

Best regards


Hello Paulo, 

The design of your architecture is an iterative process. When new concepts are introduced you need to Disclose,
Organize and Assemble the new concepts in you architecture. We realy can't answer you question without knowing the business. For example Contact_IS can be a simple wrapper around one type of contract. But is can also be that the undelying data source has a very complex structure with diffent contract type suporting different business domains. In that case I can even be wise to split at IS level. As business develop and change there an always be a case where it is wise to change you architecture. 


If I want to expose the services consumed by my Integration Services to multiple modules, should the dependencies be between the Core Service for that business domain and the other Core Service modules or should I allow my Integration Services to be consumed by other Core Services rather than the ones responsible for that business domain?

Looking at this question, the basic approch is to put common services in a separate application that can be consumed multiple times. The underlying assumption here is that these common services do not change that ofthen. For a start architecture this is a good approch. But when introducing a new consumers or concepts you should always re-evaluate your architecture to check if it still fits you business.