Microservice architecture style is gaining more and moretraction each day being the most chosen architecture by com-panies creating new enterprise applications due to advantagessuch as [insert advantages + references].Due to these advantages, there is clarity in the fact thatArchitecture has a crucial role in the software lifecycle, inorder to ensure quality and critical attributes of the software.[c23]While the microservices architecture has many definitionseach trying to better describe the concept, the author ofthis paper chose to adhere to the Martin Fowler’s definition[c1] which describe this architectural style as building anapplication as a group of services each designed for a spe-cific business capability, intercommunicating via lightweightmechanisms while being independently deployable. The con-cepts of Service Oriented Architecture (SOA) constitute thebase for Microservice Architecture (MSA) which borrowsthe idea of componentization in small services designedusing bounded contexts to merge correlated functionalities[c8] and agile development style with DevOps practices forcontinuous integration and delivery, while keeping the datamanagement and interaction of the services decentralized.MSA has different policy in regards to the sharing philosophybeing more focused on isolation and autonomy relying onchoreography, while SOA focuses on reusability relying onorchestration. [c2]Notwithstanding the existing research in the area of mi-croservices, strong interface boundaries and considering theappropriate granularity, proper automatic deployment andtesting tools, still persist as challenges inherited from SOA.The identification of ”good” microservices does not focusonly on partitioning the system for easy maintenance, butalso describes the evolution of the system and its scalingcapabilities.An important design issue that has to be considered inMSA is the functionality each service possesses, that hasto be carefully split/allocated with the appropriate granular-ity. In accordance with Conway’s Law [c6], organizationsusually produce system architectures/designs that mirror theorganization’s communication patterns. This usually occursin practice, the natural flow of interaction between thedevelopers or the teams developing a software product, beingembedded in the calls/interaction/communication betweenthe microservices/components.(This approach encourage developers to deliver qual-ity attributes in which there are no communication flaws.[c22][c21] ?)Issues present in the old monolithic architecture such asthe system becoming highly coupled, hard to maintain andenrich with new features, can be overcame by migrating toMSA, a more and more adopted option for resolving existingissues (without major cost related implications), while aidingthe system maintainability and the rate at which softwareproducts are delivered. [c19]From [c24] we discover that automated testing is thesecond most arose issue in regards to the migrating process.Regarding the architecture, the main issues identified are (1)high coupling (2) service boundaries identification dilemmas,and (3) system decomposition, [c24] in this context referringto decomposition around business capabilities. Furthermore,the decomposition process aid the architecture via reducingthe number of layers and forcing microservice’s focus aroundeach business functionality, on top of which a lightweightcommunication layer is added for integration of the resultedmicroservices.STATE GOAL OF PAPERAs service composition is a recurring issue in the processof designing a MSA [3] as well as the absence of a soundmethodology to assess the quality of microservice-orienteddecompositions [4] (combined with the fact that architectureimpact analysis is an unexplored area [3]), it is safe to assume that with all recent developments in automatizing themigration process, the validation of resulted microservicesstill lacks a clear set of quality criteria. Therefore, thegoalof this literature study survey consists of the identificationof a minimum comprehensive set of quality assessmentcriteria deemed applicable to all microservices resultedfrom migrating a monolithic application to this emergentarchitectural style.STATE CONTRIBUTIONSThe contributions of the author in this literature studysurvey consists of an refinement of the already proposedvalidation criteria for microservices throughout the existingresearch, also taking into consideration the requirementsof an automatic validation framework (based on staticanalysis?). According to [c16] In this research, we definemicroservice testing as microservice validation, because ingeneral it is impossible to apply static testing methods tothe compiled microservice.EXPLAIN THE SECTIONS THAT FOLLOW