In the "clean architecture of the Road," a book chapter Supplements Uncle Bob, Simon Brown addressed the issue of cross-organizational structure of the code or vertical cut. According to my understanding, combined with his uncle Bob for the elaborate architecture throughout, he pointed out the simple according to the traditional MVC (cross) and SOA, micro-services (vertical cut) and other disadvantages of each, presented himself on port - Adapters segmentation model of the way. This is a language package fully consider the characteristics, using the concept of access to the keywords and the package will be the way of code organization, taking into account the advantages of the first two. Not only solve the problem of traffic when no business sense to expand the hierarchical MVC coarse-grained does not meet the requirements, but also to solve the cross-package calls between services depend confusion, thermocline access problems, rather Mean.
According to Simon's structural model is a set of components and services are divided into peripheral areas (Domain) Infrastructure (Infrastructure) component that represents a set of services with a set of concentric circles. I thought it would, as I understand it to re-structure illustrated as follows: 
As the two is more, the icon with two sets of services (vertical segmentation) to represent a complete project. As can be seen, each set of upper and lower layer services (i.e., horizontal segmentation) remains the MVC architecture, but MVC degraded to the interior of each of the service use case. And each set of services respectively provide external service interface IBiz and persistence layer interface IDao, to achieve the core CoreBiz is an internal component in the privatization package. Back lateral view, two gray background, can be two large packet structure for a package containing a peripheral infrastructure (Infrastructure), in the illustrated example, the controller layer, on another package containing various services fIELD assembly (Domain). Of course, cross-package call (This refers to calls between each vertical service) is always difficult to avoid, because things border and border infrastructure is not an easy draw a line, especially in the beginning of the design. Fortunately, we can with the evolution of the common data model (or entity), common business component is pulled out to depend on other components. In the dependency between the lateral layers, VO, BO, PO needs to be adapted in the data flow, may need to extract a common or generic template ITransformVoToPo the interfaces. This may be why the architecture is called port - the reason the adapter model. Compared to the data model of all layers, using a unified entity class as a model and will fall into the heap entities dependent on the bag causing confusion, combined with ORM framework annotation type of pollution caused by the deployment package and other issues, despite the hierarchical data model adaptation needs some trouble, the benefits are very clear and easy to manage dependencies. So, on the need for a separate layer abstract entity, which is not related to the core issues of architecture, it is an implementation detail. Such functional style programming paradigm employed, the type of language with a weak dynamic languages, persistent use of non ORM frameworks, OOP can not model the manufacturing data, while the basic data structure used to achieve. This is a matter of debate, but also depends on the actual situation of the project, the development of norms and other requirements.
