MVCS

Introduction

MVCS is an application development approach that adds an additional layer to MVC -- the Service Layer. In the same way that MVC takes the position that you should separate model logic from view and controller logic, MVCS takes this notion a step further by advocating for application logic to live in the Service Layer, internally binding persistence to Entities for loose-coupling.

The main benefits of this approach are:

• Persistence-agnosticism. The Persistence Layer can evolve and even be replaced without refactoring business logic.
• Controller-agnosticism. The Service Layer can be exposed in multiple controllers. For example, the same "users" Service Layer can be used in multiple views, API versions, Thrift handlers, scripts, CLI programs, Kafka Ingesters, etc. without needing to duplicate code.
• Framework-agnosticism. The Service Layer is developed "away" from the framework being used (e.g., Flask), so upgrading or replacing it is trivial.
• Predictable development and testing patterns. Creates a common language for developing and testing different responsibilities. Abstracting persistence allows for test fixtures that don't need to interact with a database.
• Collaborative language. Moves the conversation away from how to develop and test commonly recurring functionality, to how to organize responsibilities and how different layers of an application should interact.

The Service Onion

MVCS works by dividing a domain into a common set of layers, often called the "Service Onion":

It's important to note that the inner-most layers of the Service Onion must not know about layers that live above them. For example, Entities do not know about their own persistence or the Service Layer or view or jobs in the Controller Layer. This is the same for each layer in the Service Onion and is where most of the MVCS's decoupling benefits come from.

Directory Structure

On the filesystem, these layers tend to be named after their problem domain and then organized by responsibility.

#
# Entities
#
foo/entities/user.py    # contains User entities
foo/entities/comment.py # contains Comment entities

#
# Service Layer Classes
#
foo/services/user.py    # contains UserService
foo/services/comment.py # contains CommentService

#
# Repositories
#
foo/services/repositories/user.py    # contains UserRepository
foo/services/repositories/comment.py # contains CommentRepository

#
# Gateways
#
foo/services/gateways/comment.py  # contains CommentGateway

#
# Mappers
#
foo/services/mappers/user.py    # contains UserMapper
foo/services/mappers/comment.py # contains CommentMapper

Note that all persistence layer classes are stored as modules in the services directory. This is because persistence details should be hidden by the Service Layer.

Testing

MVCS not only gives you a vocabulary and method for organizing commonly recurring functionality - it also offers predictable testing patterns. The following diagram indicates how you should think about testing each layer. Notice how integration tests are pushed to the deepest layers of our application - this ensures our test suite is always fast, but also that our assumptions on internal databases and external services are correct.

NOTE: Your Service Layer Classes should never use objects that "you don't own" - for example, if a Service Layer Class uses an ORM's library directly (like SQLAlchemy's session) then you have no choice but to write integration tests since you should NEVER mock code that you don't own.

History / Related Reading

Employing Service Layers in application development stems from the marriage of DDD (dividing a problem area by its pieces and developing a common language to refer to those pieces) & SOLID/GRASP (dividing a technical problem into loosely coupled, composable, extensible, testable, and finite objects with OO). It is often seen in languages like Java (especially in Spring), ASP.NET, & PHP (especially in Symfony). The benefits are not language specific, and can be deployed in most settings.

Check out the following readings for more insight:

• Domain-Driven Design: Tackling Complexity in the Heart of Software
• Martin Fowler - Service Layer
• Martin Fowler - Domain Model
• Martin Fowler - Data Mapper
• Martin Fowler - Repository
• Martin Fowler - Gateway
• Martin Fowler - AnemicDomainModel
• Martin Fowler - SemanticDiffusion
• Martin Fowler - Testing Strategies in a Microservice Architecture
• Writing Robust PHP Backends with Zend Framework
• Play-Doh: Modelling your Objects
• Stefan Priebsch - Why MVC is not an application architecture
• Action-Domain-Responder: a web-specific refinement of Model-View-Controller
• Jeffrey Palermo - The Onion Architecture
• Robert Martin - The Clean Architecture
• Jon Leighton - Explaining Focused Controller in Rails
• Spring Framework - Application Layering
• Dave Elkan - A Layred Node.js Architecture using Express
• Salesforce Stack Exchange - How to best structure code so it can be run synchronously and in Batch
• Stack Overflow - Service Layer validation vs. Domain Object validation
• Stack Overflow - Heavy Model Classes or Lightweight Service Layer
• Using Services to Keep Your Rails Controllers Clean and DRY
• Python SOLID
• Foundations of OOP Introduction to SOLID principles
• Foundations of OOP Introduction to GRASP principles