Revision as of 02:54, 25 September 2013 edit Wbm1058 (talk \| contribs) Autopatrolled, Administrators 278,507 edits redundancy is not obvious to me, "to get rid of this dreck" is not a valid reason to merge. these articles are suffering from buzzword overload and merging won't solve that. ← Previous edit		Revision as of 15:24, 14 November 2014 edit undo B800h (talk \| contribs) Extended confirmed users 892 edits →Rationale: Grammar fix into -> in Tags: Mobile edit Mobile web edit Next edit →
Line 6: Grouping services into functional layers reduces the impact of change. Most changes affect only the layer in which they're made, with few side-effects that impact other layers. This fundamentally simplifies service maintenance. The [[Service Reusability Principle\|service reusability]] principle dictates that services should be designed to maximize reuse. Similarly, the [[Service Composability Principle\|service composability]] principle advocates designing services so that they can be composed ~~into~~in various ways. Both principles require that a service contain only a specific type of logic e.g., either reusable or process-specific logic.<ref name='SOAMag'>[[Thomas Erl]].[http://soa.sys-con.com/node/645271?page=0,1 Introducing SOA Design Pattern][Online]. Date accessed:6 April 2010.</ref> Restricting each layer to a particular functionality, simplifies the design of the service. ==Usage==

Service layer pattern: Difference between revisions