{"id":47,"date":"2018-03-16T09:54:48","date_gmt":"2018-03-16T16:54:48","guid":{"rendered":"https:\/\/blog.kineteque.com\/?p=47"},"modified":"2018-03-16T09:54:48","modified_gmt":"2018-03-16T16:54:48","slug":"the-layered-architecture-pattern","status":"publish","type":"post","link":"https:\/\/blog.kineteque.com\/?p=47","title":{"rendered":"The Layered Architecture Pattern"},"content":{"rendered":"

Len Bass, Paul Clements, and Rick Kazman best explain the Layered Architecture as, “The Layered Architecture Pattern\u00a0defines\u00a0layers as a grouping of modules or services\u00a0and a unidirectional\u00a0allowed-to-use<\/em>\u00a0relation among layers. Layers must have a strict-ordering relation, in which a layer can only use public interfaces of a layer below,” in the book Software Architecture in Practice1<\/sup><\/span>.<\/p>\n

The benefit of the layered-architecture is that it allows for a separation of concerns, allows for a division of labor, and it is typically easy to refactor a top layer.<\/p>\n

Its drawback is that there is a performance cost\u00a0for each layer, and it can be very expensive to refactor lower layers.<\/p>\n

<\/p>\n

The Layered Architecture applied as reference architecture for a RESTful Application<\/h2>\n

\"\"<\/a><\/p>\n

The Presentation Tier<\/h3>\n

A well-designed architecture could easily switch Presentation Layer implementations with different technologies. Perhaps this could be a Swing Application, Command Line Application, or MVC framework with server side templating. This particular example documents a Layered REST application.<\/p>\n

Serialization Segment<\/h4>\n

The Serialization segment provides a set of classes per each serializable request and response types (i.e.\u00a0Plain Ordinary Java Object\u00a0that Jackson<\/a> could easily convert to and from JSON).<\/p>\n

Transformer Segment<\/h4>\n

The Transformer segment will convert\u00a0serializable request and response\u00a0classes into Domain \/ Model classes.<\/p>\n

REST Endpoint Declarations Segment<\/h4>\n

The REST Endpoint Declarations will each declare a PATH, an Accept type, a Content-Type, a serializable request class, and a serializable response class.<\/p>\n

It will receive the Serializable Request, transform it into the appropriate Domain \/ Model class, and call the appropriate Business Logic Service class, transform the result into Serializable Response, and finally respond.<\/p>\n

Business Logic Services Layer<\/h3>\n

The Business Logic Services Layer receives a domain object from the Presentation Layer, and provides business functionality. It will use the Client Interface to communicate to other components in a system or the Persistence Layer to persist data.<\/p>\n

Client Interface Layer or Persistence Layer<\/h3>\n

The Client Interface Layer is responsible for sending or receiving data from other systems.\u00a0 <\/span>This might also be a Persistence Layer that merely persist data into a data-store. For example, this could be a set of Data-access Objects that use JPA.<\/p>\n

Domain \/ Model Layer<\/h3>\n

The Domain \/ Model layer should attempt to provide an object-oriented model of your business. It is good to implement business logic here, but keep in mind that business logic computations often require external persistence, and it is anti-pattern to couple persistence technologies with a domain object. These absolutely should be Plain Ordinary Java objects, and depending your threading model, perhaps immutable as well.<\/p>\n

\n
\n
\n
\n
1.<\/div>\n
Bass L, Clements P, Kazman R. Software Architecture in Practice<\/i>. Addison-Wesley Professional; 2012.<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n","protected":false},"excerpt":{"rendered":"

Len Bass, Paul Clements, and Rick Kazman best explain the Layered Architecture as, “The Layered Architecture Pattern\u00a0defines\u00a0layers as a grouping of modules or services\u00a0and a unidirectional\u00a0allowed-to-use\u00a0relation among layers. Layers must have a strict-ordering relation, in which a layer can only use public interfaces of a layer below,” in the book Software Architecture in Practice1. The […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-47","post","type-post","status-publish","format-standard","hentry","category-architecture-patterns"],"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/blog.kineteque.com\/index.php?rest_route=\/wp\/v2\/posts\/47","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.kineteque.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.kineteque.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.kineteque.com\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.kineteque.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=47"}],"version-history":[{"count":0,"href":"https:\/\/blog.kineteque.com\/index.php?rest_route=\/wp\/v2\/posts\/47\/revisions"}],"wp:attachment":[{"href":"https:\/\/blog.kineteque.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=47"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.kineteque.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=47"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.kineteque.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=47"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}