presentation service layer

• Engineering Mathematics
• Discrete Mathematics
• Operating System
• Computer Networks
• Digital Logic and Design
• C Programming
• Data Structures
• Theory of Computation
• Compiler Design
• Computer Org and Architecture

Presentation Layer in OSI model

Prerequisite : OSI Model

Introduction : Presentation Layer is the 6th layer in the Open System Interconnection (OSI) model. This layer is also known as Translation layer, as this layer serves as a data translator for the network. The data which this layer receives from the Application Layer is extracted and manipulated here as per the required format to transmit over the network. The main responsibility of this layer is to provide or define the data format and encryption. The presentation layer is also called as Syntax layer since it is responsible for maintaining the proper syntax of the data which it either receives or transmits to other layer(s).

Functions of Presentation Layer :

The presentation layer, being the 6th layer in the OSI model, performs several types of functions, which are described below-

• Presentation layer format and encrypts data to be sent across the network.
• This layer takes care that the data is sent in such a way that the receiver will understand the information (data) and will be able to use the data efficiently and effectively.
• This layer manages the abstract data structures and allows high-level data structures (example- banking records), which are to be defined or exchanged.
• This layer carries out the encryption at the transmitter and decryption at the receiver.
• This layer carries out data compression to reduce the bandwidth of the data to be transmitted (the primary goal of data compression is to reduce the number of bits which is to be transmitted).
• This layer is responsible for interoperability (ability of computers to exchange and make use of information) between encoding methods as different computers use different encoding methods.
• This layer basically deals with the presentation part of the data.
• Presentation layer, carries out the data compression (number of bits reduction while transmission), which in return improves the data throughput.
• This layer also deals with the issues of string representation.
• The presentation layer is also responsible for integrating all the formats into a standardized format for efficient and effective communication.
• This layer encodes the message from the user-dependent format to the common format and vice-versa for communication between dissimilar systems.
• This layer deals with the syntax and semantics of the messages.
• This layer also ensures that the messages which are to be presented to the upper as well as the lower layer should be standardized as well as in an accurate format too.
• Presentation layer is also responsible for translation, formatting, and delivery of information for processing or display.
• This layer also performs serialization (process of translating a data structure or an object into a format that can be stored or transmitted easily).

Features of Presentation Layer in the OSI model: Presentation layer, being the 6th layer in the OSI model, plays a vital role while communication is taking place between two devices in a network.

List of features which are provided by the presentation layer are:

• Presentation layer could apply certain sophisticated compression techniques, so fewer bytes of data are required to represent the information when it is sent over the network.
• If two or more devices are communicating over an encrypted connection, then this presentation layer is responsible for adding encryption on the sender’s end as well as the decoding the encryption on the receiver’s end so that it can represent the application layer with unencrypted, readable data.
• This layer formats and encrypts data to be sent over a network, providing freedom from compatibility problems.
• This presentation layer also negotiates the Transfer Syntax.
• This presentation layer is also responsible for compressing data it receives from the application layer before delivering it to the session layer (which is the 5th layer in the OSI model) and thus improves the speed as well as the efficiency of communication by minimizing the amount of the data to be transferred.

Working of Presentation Layer in the OSI model : Presentation layer in the OSI model, as a translator, converts the data sent by the application layer of the transmitting node into an acceptable and compatible data format based on the applicable network protocol and architecture.  Upon arrival at the receiving computer, the presentation layer translates data into an acceptable format usable by the application layer. Basically, in other words, this layer takes care of any issues occurring when transmitted data must be viewed in a format different from the original format. Being the functional part of the OSI mode, the presentation layer performs a multitude (large number of) data conversion algorithms and character translation functions. Mainly, this layer is responsible for managing two network characteristics: protocol (set of rules) and architecture.

Presentation Layer Protocols : Presentation layer being the 6th layer, but the most important layer in the OSI model performs several types of functionalities, which makes sure that data which is being transferred or received should be accurate or clear to all the devices which are there in a closed network. Presentation Layer, for performing translations or other specified functions, needs to use certain protocols which are defined below –

• Apple Filing Protocol (AFP): Apple Filing Protocol is the proprietary network protocol (communications protocol) that offers services to macOS or the classic macOS. This is basically the network file control protocol specifically designed for Mac-based platforms.
• Lightweight Presentation Protocol (LPP): Lightweight Presentation Protocol is that protocol which is used to provide ISO presentation services on the top of TCP/IP based protocol stacks.
• NetWare Core Protocol (NCP): NetWare Core Protocol is the network protocol which is used to access file, print, directory, clock synchronization, messaging, remote command execution and other network service functions.
• Network Data Representation (NDR): Network Data Representation is basically the implementation of the presentation layer in the OSI model, which provides or defines various primitive data types, constructed data types and also several types of data representations.
• External Data Representation (XDR): External Data Representation (XDR) is the standard for the description and encoding of data. It is useful for transferring data between computer architectures and has been used to communicate data between very diverse machines. Converting from local representation to XDR is called encoding, whereas converting XDR into local representation is called decoding.
• Secure Socket Layer (SSL): The Secure Socket Layer protocol provides security to the data that is being transferred between the web browser and the server. SSL encrypts the link between a web server and a browser, which ensures that all data passed between them remains private and free from attacks.

Please Login to comment...

Similar reads.

• How to Get a Free SSL Certificate
• Best SSL Certificates Provider in India
• Elon Musk's xAI releases Grok-2 AI assistant
• What is OpenAI SearchGPT? How it works and How to Get it?
• Full Stack Developer Roadmap [2024 Updated]

Improve your Coding Skills with Practice

What kind of Experience do you want to share?

  Layer 6 Presentation Layer

De/Encryption, Encoding, String representation

The presentation layer (data presentation layer, data provision level) sets the system-dependent representation of the data (for example, ASCII, EBCDIC) into an independent form, enabling the syntactically correct data exchange between different systems. Also, functions such as data compression and encryption are guaranteed that data to be sent by the application layer of a system that can be read by the application layer of another system to the layer 6. The presentation layer. If necessary, the presentation layer acts as a translator between different data formats, by making an understandable for both systems data format, the ASN.1 (Abstract Syntax Notation One) used.

OSI Layer 6 - Presentation Layer

The presentation layer is responsible for the delivery and formatting of information to the application layer for further processing or display. It relieves the application layer of concern regarding syntactical differences in data representation within the end-user systems. An example of a presentation service would be the conversion of an EBCDIC-coded text computer file to an ASCII-coded file. The presentation layer is the lowest layer at which application programmers consider data structure and presentation, instead of simply sending data in the form of datagrams or packets between hosts. This layer deals with issues of string representation - whether they use the Pascal method (an integer length field followed by the specified amount of bytes) or the C/C++ method (null-terminated strings, e.g. "thisisastring\0"). The idea is that the application layer should be able to point at the data to be moved, and the presentation layer will deal with the rest. Serialization of complex data structures into flat byte-strings (using mechanisms such as TLV or XML) can be thought of as the key functionality of the presentation layer. Encryption is typically done at this level too, although it can be done on the application, session, transport, or network layers, each having its own advantages and disadvantages. Decryption is also handled at the presentation layer. For example, when logging on to bank account sites the presentation layer will decrypt the data as it is received.[1] Another example is representing structure, which is normally standardized at this level, often by using XML. As well as simple pieces of data, like strings, more complicated things are standardized in this layer. Two common examples are 'objects' in object-oriented programming, and the exact way that streaming video is transmitted. In many widely used applications and protocols, no distinction is made between the presentation and application layers. For example, HyperText Transfer Protocol (HTTP), generally regarded as an application-layer protocol, has presentation-layer aspects such as the ability to identify character encoding for proper conversion, which is then done in the application layer. Within the service layering semantics of the OSI network architecture, the presentation layer responds to service requests from the application layer and issues service requests to the session layer. In the OSI model: the presentation layer ensures the information that the application layer of one system sends out is readable by the application layer of another system. For example, a PC program communicates with another computer, one using extended binary coded decimal interchange code (EBCDIC) and the other using ASCII to represent the same characters. If necessary, the presentation layer might be able to translate between multiple data formats by using a common format. Wikipedia

• Data conversion
• Character code translation
• Compression
• Encryption and Decryption

The Presentation OSI Layer is usually composed of 2 sublayers that are:

CASE common application service element

SASE specific application service element

Layer 7   Application Layer

Layer 6   presentation layer, layer 5   session layer, layer 4   transport layer, layer 3   network layer, layer 2   data link layer, layer 1   physical layer.

Presentation Domain Data Layering

26 August 2015

Martin Fowler

team organization

encapsulation

application architecture

web development

One of the most common ways to modularize an information-rich program is to separate it into three broad layers: presentation (UI), domain logic (aka business logic), and data access. So you often see web applications divided into a web layer that knows about handling HTTP requests and rendering HTML, a business logic layer that contains validations and calculations, and a data access layer that sorts out how to manage persistent data in a database or remote services.

On the whole I've found this to be an effective form of modularization for many applications and one that I regularly use and encourage. It's biggest advantage (for me) is that it allows me to reduce the scope of my attention by allowing me to think about the three topics relatively independently. When I'm working on domain logic code I can mostly ignore the UI and treat any interaction with data sources as an abstract set of functions that give me the data I need and update it as I wish. When I'm working on the data access layer I focus on the details of wrangling the data into the form required by my interface. When I'm working on the presentation I can focus on the UI behavior, treating any data to display or update as magically appearing by function calls. By separating these elements I narrow the scope of my thinking in each piece, which makes it easier for me to follow what I need to do.

This narrowing of scope doesn't imply any sequence to programming them - I usually find I need to iterate between the layers. I might build the data and domain layers off my initial understanding of the UX, but when refining the UX I need to change the domain which necessitates a change to the data layer. But even with that kind of cross-layer iteration, I find it easier to focus on one layer at a time as I make changes. It's similar to the switching of thinking modes you get with refactoring's two hats .

Another reason to modularize is to allow me to substitute different implementations of modules. This separation allows me to build multiple presentations on top of the same domain logic without duplicating it. Multiple presentations could be separate pages in a web app, having a web app plus mobile native apps, an API for scripting purposes, or even an old fashioned command line interface. Modularizing the data source allows me to cope gracefully with a change in database technology, or to support services for persistence that may change with little notice. However I have to mention that while I often hear about data access substitution being a driver for separating the data source layer, I rarely hear of someone actually doing it.

Modularity also supports testability, which naturally appeals to me as a big fan of SelfTestingCode . Module boundaries expose seams that are good affordance for testing . UI code is often tricky to test, so it's good to get as much logic as you can into a domain layer which is easily tested without having to do gymnastics to access the program through a UI 1 . Data access is often slow and awkward, so using TestDoubles around the data layer often makes domain logic testing much easier and responsive.

1: A PageObject is also an important tool to help testing around UIs.

While substitutability and testability are certainly benefits of this layering, I must stress that even without either of these reasons I would still divide into layers like this. The reduced scope of attention reason is sufficient on its own.

When talking about this we can either look at it as one pattern (presentation-domain-data) or split it into two patterns (presentation-domain, and domain-data). Both points of view are useful - I think of presentation-domain-data as a composite of presentation-domain and domain-data.

I consider these layers to be a form of module, which is a generic word I use for how we clump our software into relatively independent pieces. Exactly how this corresponds to code depends on the programming environment we're in. Usually the lowest level is some form of subroutine or function. An object-oriented language will have a notion of class that collects functions and data structure. Most languages have some form of higher level called packages or namespaces, which often can be formed into a hierarchy. Modules may correspond to separately deployable units: libraries, or services, but they don't have to.

Layering can occur at any of these levels. A small program may just put separate functions for the layers into different files. A larger system may have layers corresponding to namespaces with many classes in each.

I've mentioned three layers here, but it's common to see architectures with more than three layers. A common variation is to put a service layer between the domain and presentation, or to split the presentation layer into separate layers with something like Presentation Model . I don't find that more layers breaks the essential pattern, since the core separations still remain.

The dependencies generally run from top to bottom through the layer stack: presentation depends on the domain, which then depends on the data source. A common variation is to arrange things so that the domain does not depend on its data sources by introducing a mapper between the domain and data source layers. This approach is often referred to as a Hexagonal Architecture .

These layers are logical layers not physical tiers. I can run all three layers on my laptop, I can run the presentation and domain model in a desktop with a database on a server, I can split the presentation with a rich client in the browser and a Backed For Frontend on the server. In that case I treat the BFF as a presentation layer as it's focused on supporting a particular presentation option.

Although presentation-domain-data separation is a common approach, it should only be applied at a relatively small granularity. As an application grows, each layer can get sufficiently complex on its own that you need to modularize further. When this happens it's usually not best to use presentation-domain-data as the higher level of modules. Often frameworks encourage you to have something like view-model-data as the top level namespaces; that's OK for smaller systems, but once any of these layers gets too big you should split your top level into domain oriented modules which are internally layered.

Developers don't have to be full-stack but teams should be.

One common way I've seen this layering lead organizations astray is the AntiPattern of separating development teams by these layers. This looks appealing because front-end and back-end development require different frameworks (or even languages) making it easy for developers to specialize in one or the other. Putting those people with common skills together supports skill sharing and allows the organization to treat the team as a provider of a single, well-delineated type of work. In the same way, putting all the database specialists together fits in with the common centralization of databases and schemas. But the rich interplay between these layers necessitates frequent swapping between them. This isn't too hard when you have specialists in the same team who can casually collaborate, but team boundaries add considerable friction, as well as reducing an individual's motivation to develop the important cross-layer understanding of a system. Worse, separating the layers into teams adds distance between developers and users. Developers don't have to be full-stack (although that is laudable) but teams should be.

Further Reading

I've written about this separation from a number of different angles elsewhere. This layering drives the structure of P of EAA and chapter 1 of that book talks more about this layering. I didn't make this layering a pattern in its own right in that book but have toyed with that territory with Separated Presentation and PresentationDomainSeparation .

For more on why presentation-domain-data shouldn't be the highest level modules in a larger system, take a look at the writing and speaking of Simon Brown . I also agree with him that software architecture should be embedded in code.

I had a fascinating discussion with my colleague Badri Janakiraman about the nature of hexagonal architectures. The context was mostly around applications using Ruby on Rails, but much of the thinking applies to other cases when you may be considering this approach.

Acknowledgements

Service Layer Pattern in Java: Enhancing Application Architecture with Robust Service Layers

Also known as.

• Application Facade

Intent of Service Layer Design Pattern

The Service Layer pattern is crucial for Java developers focusing on building robust application architectures that separate business processes from user interface concerns.

The pattern encapsulate business logic in a distinct layer to promote separation of concerns and to provide a well-defined API for the presentation layer.

Detailed Explanation of Service Layer Pattern with Real-World Examples

Real-world example

Imagine a complex restaurant system where orders are managed through a centralized 'service layer' to ensure efficient operation and clear communication between the front and back of the house. Each section specializes in a part of the meal, but the waitstaff don't interact directly with the kitchen staff. Instead, all orders go through a head chef who coordinates the workflow. The head chef acts like the service layer, handling the business logic (order coordination) and providing a unified interface for the waitstaff (presentation layer) to interact with the kitchen (data access layer).

In plain words

A pattern that encapsulates business logic into a distinct layer to promote separation of concerns and provide a clear API for the presentation layer.

Wikipedia says

Service layer is an architectural pattern, applied within the service-orientation design paradigm, which aims to organize the services, within a service inventory, into a set of logical layers. Services that are categorized into a particular layer share functionality. This helps to reduce the conceptual overhead related to managing the service inventory, as the services belonging to the same layer address a smaller set of activities.

Programmatic Example of Service Layer Pattern in Java

Our Java implementation uses the Service Layer pattern to streamline interactions between data access objects (DAOs) and the business logic, ensuring a clean separation of concerns.

The example application demonstrates interactions between a client App and a service MagicService that allows interaction between wizards, spellbooks and spells. The service is implemented with 3-layer architecture (entity, dao, service).

For this explanation we are looking at one vertical slice of the system. Let's start from the entity layer and look at Wizard class. Other entities not shown here are Spellbook and Spell .

Above the entity layer we have DAOs. For Wizard the DAO layer looks as follows.

Next we can look at the Service Layer, which in our case consists of a single MagicService .

And finally, we can show how the client App interacts with MagicService in the Service Layer.

The program output:

When to Use the Service Layer Pattern in Java

• Use when you need to separate business logic from presentation logic.
• Ideal for applications with complex business rules and workflows.
• Suitable for projects requiring a clear API for the presentation layer.

Real-World Applications of Service Layer Pattern in Java

• Java EE applications where Enterprise JavaBeans (EJB) are used to implement the service layer.
• Spring Framework applications using the @Service annotation to denote service layer classes.
• Web applications that need to separate business logic from controller logic.

Benefits and Trade-offs of Service Layer Pattern

Implementing a Service Layer in Java

• Promotes code reuse by encapsulating business logic in one place.
• Enhances testability by isolating business logic.
• Improves maintainability and flexibility of enterprise applications.

Trade-offs:

• May introduce additional complexity by adding another layer to the application.
• Can result in performance overhead due to the extra layer of abstraction.

Related Java Design Patterns

• Facade : Simplifies interactions with complex subsystems by providing a unified interface.
• DAO (Data Access Object) : Often used together with the Service Layer to handle data persistence.
• MVC (Model-View-Controller) : The Service Layer can be used to encapsulate business logic in the model component.

References and Credits

• Core J2EE Patterns: Best Practices and Design Strategies
• Patterns of Enterprise Application Architecture
• Spring in Action
• Service Layer (Martin Fowler)

• Network infrastructure

presentation layer

• Andrew Froehlich, West Gate Networks

What is the presentation layer?

The presentation layer resides at Layer 6 of the Open Systems Interconnection ( OSI ) communications model and ensures that communications that pass through it are in the appropriate form for the recipient application. In other words, the presentation layer presents the data in a readable format from an application layer perspective.

For example, a presentation layer program could format a file transfer request in binary code to ensure a successful file transfer . Because binary is the most rudimentary of computing languages, it ensures that the receiving device can decipher and translate it into a format the application layer understands and expects.

How the presentation layer works

Once the application layer passes data meant for transport to another device in a certain format, the presentation layer then prepares this data in the most appropriate format the receiving application can understand.

Common data formats include the following:

• American Standard Code for Information Interchange and Extended Binary Coded Decimal Interchange Code for text;
• JPEG , GIF and TIFF for images; and
• MPEG, MIDI and QuickTime for video.

Encryption and decryption of data communications are also performed at the presentation layer. Here, encryption methods and keys exchange between the two communicating devices. Only the sender and receiver can properly encode and decode data so it returns to a readable format.

The presentation layer can serialize -- or translate -- more complex application data objects into a storable and transportable format. This helps to rebuild the object once it arrives at the other side of the communications stream. The presentation layer also deserializes the data stream and places it back into an object format that the application can understand by the application.

The tool that manages Hypertext Transfer Protocol ( HTTP ) is an example of a program that loosely adheres to the presentation layer of OSI.

Although it's technically considered an application-layer protocol per the TCP/IP model , HTTP includes presentation layer services within it. HTTP works when the requesting device forwards user requests passed to the web browser onto a web server elsewhere in the network.

HTTP receives a return message from the web server that includes a Multipurpose Internet Mail Extensions ( MIME ) header. The MIME header indicates the type of file -- text, video, or audio -- that has been received so that an appropriate player utility can present the file to the user.

Functions of the presentation layer

• ensures proper formatting and delivery to and from the application layer;
• performs data encryption; and
• manages serialization of data objects.

Editor's note: This article was republished in January 2023 to improve the reader experience.

Continue Reading About presentation layer

• What is the difference between TCP/IP model vs. OSI model?
• Data and file formatting

Related Terms

Dig deeper on network infrastructure.

What are the most important email security protocols?

file extension (file format)

network protocol

MIME (Multipurpose Internet Mail Extensions)

Microsoft 365 Copilot, an AI assistant, offers several promising features. Find out how to configure Copilot with Teams workflows...

With its AI capabilities, Microsoft Copilot provides several enhancements to Microsoft Teams functionality, including meeting ...

Organizations have ramped up their use of communications platform as a service and APIs to expand communication channels between ...

To keep corporate and user data safe, IT must continuously ensure mobile app security. Mobile application security audits are a ...

Dell continues to cut its workforce to become 'leaner,' as it repositions for changes in the enterprise PC market that are ...

Tap to Pay makes it possible to accept customer payments from an iPhone with no additional hardware. Find out the best use cases ...

Due to rapid AI hardware advancement, companies are releasing advanced products yearly to keep up with the competition. The new ...

AMD plans to acquire AI systems designer and manufacturer ZT Systems for $5 billion. AMD CEO Lisa Su said hyperscalers want more ...

Data center modernization offers a competitive advantage to organizations, along with maximizing hyperscale infrastructure. ...

Popular pricing models for managed service providers include monitoring only, per device, per user, all-you-can-eat or ...

Global IT consultancies take a multilayered approach to GenAI training by developing in-house programs, partnering with tech ...

IT service providers are upskilling a large portion of their workforces on the emerging technology. The campaign seeks to boost ...

Exploring the 3 layers of software interactions (APIs)

Application Programming Interfaces, commonly known as APIs, are a set of protocols, routines, and tools that enable software applications to interact with each other. They allow different software applications to exchange information seamlessly and efficiently.

APIs have become increasingly important in today's digital world, as they enable developers to build powerful applications that can connect with other services and platforms. APIs can be broken down into three different layers, each of which serves a different purpose.

In this blog post, we will explore the three layers of APIs and what they do.

1. Presentation Layer

The presentation layer, also known as the "API endpoint," is the layer that developers interact with most frequently. This layer provides a user-friendly interface for developers to access the functionality and data of the underlying service. It is responsible for processing incoming requests and returning responses in a format that developers can easily understand.

The presentation layer can take many different forms, depending on the requirements of the API. It could be a REST API that uses HTTP requests to exchange data or a SOAP API that uses XML messages to communicate. Regardless of the specific implementation, the presentation layer is the public-facing aspect of the API and is the first point of contact for developers.

2. Business Logic Layer

The business logic layer, also known as the "API middleware," is the layer that contains the core logic of the API. It is responsible for processing the requests received from the presentation layer and generating responses based on the requested actions.

The business logic layer is where the API's core functionality resides. It may perform data validation, authentication and authorization, database queries, or other complex operations. This layer is typically developed by the service provider and is not exposed directly to developers.

3. Data Storage Layer

The data storage layer, also known as the "API database," is the layer where all of the data used by the API is stored. This layer is responsible for managing data storage, retrieval, and modification. It may use a variety of database technologies such as SQL, NoSQL, or object-oriented databases.

The data storage layer is the most critical component of the API since it holds the data that the API relies on. If the data storage layer fails, the entire API may fail. Therefore, it is crucial to ensure that the data storage layer is designed and implemented correctly.

In conclusion, APIs consist of three layers: presentation layer, business logic layer, and data storage layer. Each layer plays a crucial role in the API's functionality and performance. Understanding the three layers of an API is essential for developers looking to build robust, reliable, and scalable APIs.

Related articles

What is Application Programming Interface (API)?

An API is a set of rules and practices that allow two applications to communicate. This means that one can use one application to retrieve data from another application or send data to another application.

Architecture of Spring Boot: Examples, Pattern, Layered, Controller Layer

Varun Saharawat is a seasoned professional in the fields of SEO and content writing. With a profound knowledge of the intricate aspects of these disciplines, Varun has established himself as a valuable asset in the world of digital marketing and online content creation.

Master the architecture of Spring Boot with our insightful blog. We'll illustrate key concepts through examples, design patterns, and discuss the significance of a well-structured layered approach!

Architecture of Spring Boot: Several application development frameworks are available, but one of the most popular frameworks when working with Java is the Spring framework. You will be completely fascinated with the Spring framework and its ability to manage applications.

Spring Boot is a Spring Framework module. It is used to quickly construct standalone, production-grade Spring Based Applications. It is built on top of the Spring Framework. Spring Boot has a layered architecture in which each layer communicates with the layer below or above it.

In this article, we will learn about the architecture of Spring Boot. We will also learn about the different layers in the Spring boot architecture. We will also learn about flow in Spring Boot Architecture.

If you want to make a successful career in Full Stack Web Development, the PhysicsWallah’s Full Stack Web Development course is just what you need! Our course will equip you with all the necessary skills and knowledge needed to become a highly successful Full Stack Web Developer in 2024! So, don’t wait! Use the coupon code “ READER” and avail an exclusive discount on all PW Skills courses.

Table of Contents

Spring Boot Architecture Example

• Controller Layer:
• This layer is responsible for handling incoming HTTP requests.
• Controllers receive requests, process them, and interact with the service layer to retrieve or manipulate data.
• Controllers are often annotated with @Controller or @RestController.
• Service Layer:
• The service layer contains business logic and acts as an intermediary between the controller and the data access layer.
• It encapsulates the application’s business logic, ensuring separation of concerns.
• Services are often annotated with @Service.
• Repository/DAO Layer:
• This layer is responsible for interacting with the database or any external data source.
• It includes interfaces or classes that define methods for performing CRUD (Create, Read, Update, Delete) operations.
• Repositories are often annotated with @Repository.
• Entity Layer:
• Entities represent the application’s data model and are often mapped to database tables.
• These classes typically contain fields annotated with JPA annotations (@Entity, @Column, etc.) for database mapping.
• DTO (Data Transfer Object):
• DTOs are used to transfer data between layers and can help to encapsulate the data being sent between the client and the server.
• They can be used to shape the data for presentation without exposing the internal entity structure.
• Security Layer:
• This layer is responsible for handling authentication and authorization.
• Spring Security is commonly used to secure Spring Boot applications, providing features like authentication, authorization, and protection against common security vulnerabilities.
• Configuration Layer:
• This layer includes configuration files and classes.
• Configuration can be done using annotations like @Configuration, @Bean, or through XML configuration.

Remember that Spring Boot is highly customizable, and the architecture can be adapted based on project requirements. This overview provides a general structure that many Spring Boot applications follow.

Spring Boot Architecture Patterns

Spring Boot applications often follow certain architectural patterns to achieve modularity, scalability, and maintainability. Here are some common architectural patterns used in Spring Boot development:

• MVC (Model-View-Controller):
• Spring Boot follows the MVC pattern for building web applications.
• Model: Represents the application’s data and business logic.
• View: Responsible for rendering the user interface.
• Controller: Handles user requests, interacts with the model, and updates the view.
• Microservices Architecture:
• Spring Boot is commonly used in microservices architectures where the application is decomposed into small, independently deployable services.
• Each microservice is responsible for a specific business capability and communicates with other services through APIs.
• Restful API Design:
• Spring Boot promotes the design of RESTful APIs for communication between components.
• Controllers expose RESTful endpoints, and data is typically exchanged in JSON format.
• Layered Architecture:
• Organising the application into layers like presentation, service, repository, and entity helps maintain a separation of concerns.
• This layered architecture promotes modularity and testability.
• Dependency Injection (DI) / Inversion of Control (IoC):
• Spring Boot relies heavily on the principle of dependency injection, where dependencies are injected into components rather than being created by the components themselves.
• This reduces tight coupling and makes the application more maintainable.
• Event-Driven Architecture:
• Spring Boot supports event-driven architecture through the use of Spring Events.
• Components can publish and subscribe to events, allowing for loosely coupled communication between different parts of the application.
• CQRS (Command Query Responsibility Segregation):
• CQRS separates read and write operations, allowing for independent scaling of the query (read) and command (write) sides.
• Spring Boot can be used to implement CQRS patterns using different components for command and query responsibilities.
• Saga Pattern:
• In microservices architectures, the saga pattern is often used to manage distributed transactions.
• Spring Boot applications can implement sagas by coordinating a series of transactions across multiple microservices.
• Gateway Pattern:
• API gateways are used to manage and route requests in microservices architectures.
• Spring Cloud provides tools like Spring Cloud Gateway for building API gateways.

These patterns can be combined and adapted based on the specific requirements of the application. The flexibility of Spring Boot allows developers to choose and implement the patterns that best suit their needs.

Also Read: Algorithms In Java: List, Programs, Interview Questions

Spring Boot Layered Architecture Example

Let’s walk through a layered architecture example for a Spring Boot application without providing specific code. This example assumes a typical three-layered architecture: Presentation, Service, and Data Access layers.

• Presentation Layer:
• This layer handles the interaction with the user, receives HTTP requests, and sends responses.
• Controllers in this layer are annotated with @RestController.
• The controllers interact with the Service layer to process requests and obtain results.
• DTOs (Data Transfer Objects) may be used to transfer data between the Presentation and Service layers.
• The Service layer contains business logic and orchestrates the flow of data between the Presentation and Data Access layers.
• Service classes are annotated with @Service.
• They use the Data Access layer to retrieve or manipulate data.
• This layer is responsible for enforcing business rules and ensuring data consistency.
• Data Access Layer:
• The Data Access layer is responsible for interacting with the database or any other data source.
• It includes repository interfaces or classes annotated with @Repository.
• Entities represent the data model and are often annotated with JPA annotations for database mapping.

Example Workflow:

• A user sends an HTTP request to a REST endpoint in the Presentation layer.
• The controller in the Presentation layer receives the request and invokes the appropriate method in the Service layer.
• The Service layer performs business logic, possibly involving multiple service classes, and interacts with the Data Access layer to retrieve or persist data.
• The Data Access layer communicates with the database to perform CRUD operations on entities.
• The Service layer returns the result to the Presentation layer, possibly transforming entities into DTOs.
• The Presentation layer sends an HTTP response to the user.
• Modularity: Each layer has a specific responsibility, making the application more modular and easier to maintain.
• Separation of Concerns: The separation of layers allows for a clear distinction between presentation, business logic, and data access concerns.
• Testability: Each layer can be tested independently, promoting easier unit testing and maintenance.
• Scalability: Components can be scaled independently based on the specific needs of each layer.

Considerations:

• Care should be taken to avoid tight coupling between layers. Dependency injection and interfaces can help achieve loose coupling.
• DTOs may be used to transfer data between layers, but excessive use should be avoided to prevent overcomplicating the architecture.

Remember that this is a high-level overview, and specific project requirements may lead to variations in the architecture.

Architecture of Spring Boot Microservices

The architecture of Spring Boot microservices typically follows principles that align with the characteristics of microservices, such as modularity, independence, and distributed systems. Here’s a conceptual overview of the architecture for a Spring Boot microservices application:

• Microservices:
• The application is decomposed into small, independent, and loosely coupled services, each focused on a specific business capability.
• Microservices communicate with each other through well-defined APIs, often exposed as RESTful endpoints.
• Service Registry and Discovery:
• Services register themselves with a service registry (e.g., Spring Cloud Netflix Eureka).
• Service discovery allows services to locate and communicate with each other dynamically.
• API Gateway:
• An API Gateway (e.g., Spring Cloud Gateway, Netflix Zuul) is used to manage and route external requests to the appropriate microservices.
• It can handle authentication, load balancing, and routing.
• Configuration Management:
• Centralised configuration management (e.g., Spring Cloud Config) allows microservices to retrieve configuration properties dynamically.
• Configuration can be stored in a version-controlled repository and updated without redeploying services.
• Distributed Data Management:
• Microservices often have their own databases, and the choice of database depends on the specific requirements of each service.
• Eventual consistency and distributed data management strategies may be employed.
• Events and messaging systems (e.g., Spring Cloud Stream, Apache Kafka) are used for communication between microservices.
• Event-driven architecture supports loose coupling and scalability.
• Polyglot Architecture:
• Each microservice can be implemented in a different programming language or use a different technology stack, known as a polyglot architecture.
• The choice of technology is based on the specific requirements of each service.
• Testing and Continuous Integration/Continuous Deployment (CI/CD):
• Microservices are independently testable, allowing for easier unit testing and integration testing.
• CI/CD pipelines enable automated testing and deployment of microservices.
• Domain-Driven Design (DDD):
• Microservices are often designed based on domain-driven design principles, emphasising a clear understanding of the business domain and its interactions.

This architecture allows for flexibility, scalability, and easy maintenance of a microservices-based system. Spring Cloud provides a set of tools and libraries to implement many of these patterns and streamline the development of microservices in a Spring Boot environment.

Also Read: Spring Boot Tutorial

Controller Layer in Spring Boot

In a Spring Boot application, the controller layer is a crucial component responsible for handling incoming HTTP requests, processing them, and producing appropriate responses. It plays a key role in the Model-View-Controller (MVC) architectural pattern. Below are key aspects and responsibilities of the controller layer in Spring Boot:

• Annotation:
• Controllers are typically annotated with @Controller or @RestController. The @RestController annotation is often used for RESTful APIs and includes the @Controller and @ResponseBody annotations.
• Request Mapping:
• Controllers define methods that handle specific HTTP requests. These methods are annotated with @RequestMapping or more specialised annotations like @GetMapping, @PostMapping, etc.
• Request mappings specify the URI path and HTTP method that the method should respond to.
• Method Parameters:
• Controller methods can have parameters that are automatically populated with data from the HTTP request, such as path variables (@PathVariable), request parameters (@RequestParam), request headers (@RequestHeader), and the request body.
• Response Handling:
• Controller methods return data that will be included in the HTTP response. The return type can be a Java object, which is automatically converted to JSON (or another format) using Spring’s content negotiation.
• For RESTful APIs, the @ResponseBody annotation can be used to indicate that the return value should be serialised directly to the response body.
• View Rendering (for MVC):
• In traditional MVC applications, where server-side rendering is used, the controller may return a logical view name that is resolved by the ViewResolver to an actual view template.
• For RESTful APIs, the focus is on data returned as JSON or XML rather than rendering HTML views.
• Exception Handling:
• Controllers can handle exceptions using @ExceptionHandler methods. These methods define how the application should respond when a specific exception occurs during request processing.
• Validation:
• Controllers may perform input validation by using validation annotations such as @Valid in method parameters. Validation errors can be captured and handled in the controller.
• Interception and Filters:
• Controllers can be intercepted using interceptors (HandlerInterceptor) to perform pre- or post-processing logic.
• Filters (javax.servlet.Filter) can also be applied at the servlet level for more fine-grained request processing.
• Cross-Origin Resource Sharing (CORS) Handling:
• For web applications, controllers can configure CORS settings using annotations like @CrossOrigin to control which domains are allowed to access the resources.
• Controllers often play a role in handling security aspects such as authentication and authorization. Spring Security can be integrated to secure controller methods.
• Controllers are unit-testable. Spring provides testing support through @WebMvcTest for testing the controller layer in isolation.

The controller layer acts as an interface between the external world (HTTP requests) and the application’s business logic (service layer). It helps in maintaining a clear separation of concerns in the application architecture.

What is Spring Boot Architecture?

Spring Boot follows a modular and opinionated architectural pattern that simplifies the development of production-ready, stand-alone Spring-based applications. It builds on the concepts of the broader Spring Framework and provides defaults for convention over configuration, allowing developers to quickly set up and deploy applications. 

Here’s an overview of the key components in the architecture of a Spring Boot application:

• Standalone Application:
• Spring Boot applications are designed to be standalone, meaning they are self-contained and can be run with minimum configuration. They don’t require external servlet containers like Tomcat or Jetty, as they embed an embedded server (typically Tomcat, Jetty, or Undertow).
• Opinionated Defaults:
• Spring Boot provides a set of defaults and conventions for configuration, reducing the need for extensive boilerplate code.
• It aims to minimise the effort required for developers to configure and set up the application, making it easier to get started quickly.
• Spring Framework Core:
• At its core, Spring Boot is built on top of the Spring Framework. It inherits the fundamental concepts of Inversion of Control (IoC), Dependency Injection (DI), and Aspect-Oriented Programming (AOP) from the Spring Framework.

What Is the Production Architecture of Spring Boot?

The production architecture of a Spring Boot application typically involves deploying microservices in containerized environments with orchestration (e.g., Kubernetes), load balancing, and service discovery. Cloud-native principles, such as containerization with Docker, API gateways (e.g., Spring Cloud Gateway), security measures (e.g., OAuth), and continuous integration/deployment (CI/CD) pipelines are employed. Monitoring tools (e.g., Spring Boot Actuator), logging (e.g., SLF4J with Logback), and resilience patterns (e.g., circuit breakers) ensure robustness. 

The choice of databases, scalability, and adherence to compliance regulations contribute to a production-ready architecture, providing high availability, fault tolerance, and efficient resource utilisation.

Also Read: Spring Boot Rest API: Rest APIS with Java and Spring Boot

What is the Architecture of Spring Boot Repository?

The architecture of a Spring Boot repository typically involves the use of Spring Data JPA or other data access technologies. Repositories, annotated with @Repository, encapsulate data access logic and connect the application’s service layer to the underlying database. Entities represent the data model, annotated with JPA annotations for database mapping. 

The Service layer orchestrates business logic and interacts with repositories to perform CRUD operations. Spring Boot’s auto-configuration simplifies repository setup, and custom repositories may extend CrudRepository or JpaRepository. This architecture supports modular, maintainable, and scalable applications with efficient database interactions.

What is 3 tier Architecture in Spring Boot?

The 3-tier architecture in Spring Boot divides an application into three layers: Presentation, Service, and Data Access. The Presentation layer includes controllers handling user interactions, the Service layer encapsulates business logic, and the Data Access layer manages interactions with the database.

Controllers process HTTP requests, invoking service methods that orchestrate business logic. Service classes interact with repositories or DAOs, which, in turn, perform database operations on entities. This modular architecture enhances maintainability, scalability, and separation of concerns, allowing each layer to be developed and tested independently, fostering a clearer organisation of code and facilitating future modifications.

Spring Boot offers a streamlined architecture for building Java applications. Its key features include auto-configuration, embedded servers, and a simplified setup, making it a popular choice for developing robust and production-ready applications with minimal boilerplate code and configuration.

For Latest Tech Related Information, Join Our Official Free Telegram Group : PW Skills Telegram Group

Architecture of Spring Boot FAQs

What is the key component of spring boot architecture.

The core component is the embedded web server that eliminates the need for external servlet containers, making Spring Boot applications standalone and easily deployable.

How does Spring Boot simplify configuration?

Spring Boot simplifies configuration through auto-configuration, providing sensible defaults and reducing the need for extensive manual configuration.

What role does the Spring Boot Actuator play in production?

Spring Boot Actuator provides production-ready features for monitoring and managing applications, including health checks, metrics, and application environment details.

How does Spring Boot support containerization?

Spring Boot applications can be easily containerized using Docker, allowing for consistent deployment across different environments and facilitating cloud-native development.

What is the significance of Spring Boot Starters?

Spring Boot Starters are pre-configured templates that include common dependencies, simplifying dependency management and accelerating the setup of specific functionalities like web applications, data access, and messaging.

• Unlock The Power Of Java And Data Structures With Decode Java With DSA 1.0!

PW Skills introduce a new short-term course: Decode Java With DSA 1.0 batch - a comprehensive course that will take…

• Full Stack Java Developer Syllabus (A Comprehensive Guide)

Full Stack Java Developer Syllabus helps you to understand what will be covered in your full stack Java developer course.…

• How and why is Java platform independent?

Java stands out as a widely popular programming language known for its versatility. Java doesn’t tie you down to a…

Related Articles

• OOPs Concepts in Java with Examples & Interview Questions
• Top 7 Reasons to Learn Java
• Understanding Association, Aggregation, and Composition in Java
• Armstrong Number In Java: All You Need to Know
• If Else Statement Java with Examples
• How to Make DOM in JavaScript?
• Which is Best Site to Learn Java?

Presentation Layer: Protocols, Examples, Services | Functions of Presentation Layer

Presentation Layer is the 6th layer in the Open System Interconnection (OSI) model where all application programmer consider data structure and presentation, beyond of simply sending the data into form of datagram otherwise packets in between the hosts. Now, we will explain about what is presentation layer with its protocols, example, service ; involving with major functions of presentation Layer with ease. At the end of this article, you will completely educate about What is Presentation Layer in OSI Model without any hassle.

What is Presentation Layer?

Presentation layer is capable to handle abstract data structures, and further it helps to defined and exchange of higher-level data structures.

Presentation Layer Tutorial Headlines:

Let’s get started,   functions of presentation layer.

Presentation layer performs various functions in the OSI model ; below explain each one – 

Protocols of Presentation Layer

Example of presentation layer protocols:.

Here, we will discuss all examples of presentation layer protocols; below explain each one –  

Multipurpose Internet Mail Extensions (MIME) : MIME protocol was introduced by Bell Communications in 1991, and it is an internet standard that provides scalable capable of email for attaching of images, sounds and text in a message.

Network News Transfer Protocol (NNTP) : This protocol is used to make connection with Usenet server and transmit all newsgroup articles in between system over internet.

Apple Filing Protocol (AFP ) : AFP protocol is designed by Apple company for sharing all files over the entire network .

NetWare Core Protocol (NCP) : NCP is a Novell client server model protocol that is designed especially for Local Area Network (LAN). It is capable to perform several functions like as file/print-sharing, clock synchronization, remote processing and messaging.

Network Data Representation (NDR) : NDR is an data encoding standard, and it is implement in the Distributed Computing Environment (DCE).

Tox : The Tox protocol is sometimes regarded as part of both the presentation and application layer , and it is used for sending peer-to-peer instant-messaging as well as video calling.

eXternal Data Representation (XDR) : This protocol provides the description and encoding of entire data, and  it’s main goal is to transfer data in between dissimilar computer architecture.

Presentation Layer Services

Design issues with presentation layer, faqs (frequently asked questions), what is meant by presentation layer in osi model.

Presentation Layer is the 6th layer in the Open System Interconnection (OSI) model that is the lowest layer, where all application programmer consider data structure and presentation, beyond of simply sending the data into form of datagram otherwise packets in between the hosts.

What protocols are used in the presentation layer?

Can you explain some presentation layer examples, what are the main functions of the presentation layer, what are services of presentation layer in osi.

Presentation layer has a responsibility for formatting, translation, and delivery of the information for getting to process otherwise display .

Now, i hope that you have completely learnt about what is presentation layer with its protocols, example, service ; involving with major functions of presentation Layer with ease. If this post is useful for you, then please share it along with your friends, family members or relatives over social media platforms like as Facebook, Instagram, Linked In, Twitter, and more.

Also Read: Data Link Layer: Protocols, Examples | Functions of Data Link Layer

Related posts.

Design of Service Layer and Application Logic ¶

This article is about organizing Application Logic and designing the Service Layer , Use Case, CQRS, Event Sourcing, MVC, etc.

• Design of Service Layer and Application Logic
• Layered Architecture
• What is Business Logic?
• Subtypes of Business Rules
• Why is separation of Business Logic from Application Logic so important?
• Ways to Organize Application Logic
• What is Service?
• Domain Service
• Application Service
• Infrastructure Service
• Orchestration Service
• Common mistakes of design Choreography Service
• Service types by communication
• Stateless Service
• Statefull Service
• Destination of Service Layer
• When not to use Service Layer?
• Service is not a wrapper for Data Mapper
• Implementation of Service Layer
• Inversion of control
• Widespread problem of Django applications
• Problems of Django annotation
• Peculiar properties of Service Layer on client side
• Concurrent update issue
• Event Sourcing
• Further Reading

Layers of logic ¶

Before digging deep into it, it would be nice to understand what Application Logic is and how it differs from Business Logic.

Layered Architecture ¶

One of the most cited definitions of key conceptual layers gives Eric Evans:

User Interface (or Presentation Layer) Responsible for showing information to the user and interpreting the user’s commands. The external actor might sometimes be another computer system rather than a human user. Application Layer Defines the jobs the software is supposed to do and directs the expressive domain objects to work out problems. The tasks this layer is responsible for are meaningful to the business or necessary for interaction with the application layers of other systems. This layer is kept thin. It does not contain business rules or knowledge, but only coordinates tasks and delegates work to collaborations of domain objects in the next layer down. It does not have state reflecting the business situation, but it can have state that reflects the progress of a task for the user or the program. Domain Layer (or Model Layer) Responsible for representing concepts of the business, information about the business situation, and business rules . State that reflects the business situation is controlled and used here, even though the technical details of storing it are delegated to the infrastructure. This layer is the heart of business software. Infrastructure Layer Provides generic technical capabilities that support the higher layers: message sending for the application, persistence for the domain, drawing widgets for the UI, and so on. The infrastructure layer may also support the pattern of interactions between the four layers through an architectural framework. - “Domain-Driven Design: Tackling Complexity in the Heart of Software” [4] by Eric Evans

Ward Cunningham gives us the next definitions:

Factor your application classes into four layers in the following way (see Figure 1: FourLayerArchitecture): The View layer. This is the layer where the physical window and widget objects live. It may also contain Controller classes as in classical MVC. Any new user interface widgets developed for this application are put in this layer. In most cases today this layer is completely generated by a window-builder tool. The ApplicationModel layer. This layer mediates between the various user interface components on a GUI screen and translates the messages that they understand into messages understood by the objects in the domain model. It is responsible for the flow of the application and controls navigation from window to window. This layer is often partially generated by a window-builder and partially coded by the developer. The DomainModel layer. This is the layer where most objects found in an OO analysis and design will reside. Examples of the types of objects found in this layer may be Orders, Employees, Sensors, or whatever is appropriate to the problem domain. The Infrastructure layer. This is where the objects that represent connections to entities outside the application (specifically those outside the object world) reside. Examples of objects in this layer would include SQLTables, 3270Terminals, SerialPorts, SQLBrokers and the like. - Four Layer Architecture , Ward Cunningham

But what does the term Business itself mean? Misunderstanding of this term often leads to significant design problems.

What is Business Logic? ¶

The most authoritative explanation of the term Business can be found, as usual, on the Ward Cunningham website:

Software intersects with the Real World. Imagine that.

There you can find a definition of Business Rule :

A Business Rule (in a programming context) is knowledge that gets applied to a set of data to create new value. Or it may be a rule about how to create, modify, or remove data. Or perhaps it is a rule that specifies when certain processes occur. For example, we have a rule about email addresses – when the Driver Name field on our object identifier changes, we erase the email address. When we receive a new email address, we make sure that it contains an “@” sign and a valid domain not on our blacklist.

Business Logic Definition :

Business logic is that portion of an enterprise system which determines how data is: Transformed and/or calculated. For example, business logic determines how a tax total is calculated from invoice line items. Routed to people or software systems, aka workflow.

The term Business should be distinguished from the term Business Domain :

A category about the business domain, such as accounting, finance, inventory, marketing, tracking, billing, reporting, charting, taxes, etc.

You should also distinguish Business from Business Process :

A Business Process is some reproduceable process within an organization. Often it is a something that you want to setup once and reuse over and over again. Companies spend a lot of time and money identifying Business Processes, designing the software that captures a Business Process and then testing and documenting these processes. One example of a Business Process is “Take an order on my web site”. It might involve a customer, items from a catalog and a credit card. Each of these things is represented by business objects and together they represent a Business Process.

Wikipedia gives us the following definition of the term Business Logic :

In computer software, business logic or domain logic is the part of the program that encodes the real-world Business Rules that determine how data can be created, stored, and changed. It is contrasted with the remainder of the software that might be concerned with lower-level details of managing a database or displaying the user interface, system infrastructure, or generally connecting various parts of the program.

And explains how Business Logic differs from Business Rules:

Business logic should be distinguished from business rules.[“ Definition of business logic “] Business logic is the portion of an enterprise system which determines how data is transformed or calculated, and how it is routed to people or software (workflow). Business rules are formal expressions of business policy. Anything that is a process or procedure is business logic, and anything that is neither a process nor a procedure is a business rule. Welcoming a new visitor is a process (workflow) consisting of steps to be taken, whereas saying every new visitor must be welcomed is a business rule. Further, business logic is procedural whereas business rules are declarative.[William Ulrich. “ OMG Business Rules Symposium ” (archived from the original on 2013-12-24)]

Craig Larman sees the term Business as synonymous with Domain, and in “Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development”, he cites them side by side many times, complementing one term with another in parentheses. He gives the next definition for the term Business Rules:

Business Rules - Business rules (also called Domain Rules) typically describe requirements or policies that transcend one software project - they are required in the domain or business, and many applications may need to conform to them. An excellent example is government tax laws. Domain rule details may be recorded in the Supplementary Specification, but because they are usually more enduring and applicable than for one software project, placing them in a central Business Rules artifact (shared by all analysts of the company) makes for better reuse of the analysis effort. <...> The Business Rules (or Domain Rules) capture long-living and spanning rules or policies, such as tax laws, that transcend one particular application. <...> Domain rules [Ross97, GK00] dictate how a domain or business may operate. They are not requirements of any one application, although an application’s requirements are often influenced by domain rules. Company policies, physical laws (such as how oil flows underground), and government laws are common domain rules. They are commonly called business rules, which is the most common type, but that term is poor, as many software applications are for non-business problems, such as weather simulation or military logistics. A weather simulation has “domain rules,” related to physical laws and relationships, that influence the application requirements. It’s useful to identify and record domain rules in a separate application-independent artifact - what the UP calls the Business Rules artifact - so that this analysis can be shared and reused across the organization and across projects, rather than buried within a project-specific document. —“Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development” by Craig Larman

Let me summarize this in my own words:

Subtypes of Business Rules ¶

In “Clean Architecture,” Robert Martin divides Business Rules into two types:

Application-specific Business Rules

Application-independent Business Rules

Thus we find the system divided into decoupled horizontal layers—the UI, application-specific Business Rules, application-independent Business Rules, and the database, just to mention a few. - “Clean Architecture: A Craftsman’s Guide to Software Structure and Design” [2] by Robert C. Martin

Chapters 16, 20 and 22 of Clean Architecture explain in detail the types of Business Rules.

At the same time, Robert Martin their outputs 4 layers : Entities, Use Cases, Interface Adapters, Frameworks and Drivers.

It should be noted that by “Business Rules” Robert Martin means not only rules, but also procedures, blurring the line between “Business Rules” and “Business Logic”:

Strictly speaking, business rules are rules or procedures that make or save the business money. - “Clean Architecture: A Craftsman’s Guide to Software Structure and Design” [2] by Robert C. Martin, Chapter 20 “Business Rules”

Here is a slight contradiction. On the one hand, he reduces the whole essence of “Business Rules” to the fact that they belong exclusively to the real world:

Strictly speaking, business rules are rules or procedures that make or save the business money. Very strictly speaking, these rules would make or save the business money, irrespective of whether they were implemented on a computer . They would make or save money even if they were executed manually . The fact that a bank charges N% interest for a loan is a business rule that makes the bank money. It doesn’t matter if a computer program calculates the interest, or if a clerk with an abacus calculates the interest. - “Clean Architecture: A Craftsman’s Guide to Software Structure and Design” [2] by Robert C. Martin, Chapter 20 “Business Rules”

Next Robert Martin says important information - “Business Rules” are the reason for the existence of the Application. It follows from this that the Application can no longer be the cause for the existence of “Business Rules”:

Business rules are the reason a software system exists. They are the core functionality. They carry the code that makes, or saves, money. They are the family jewels. The business rules should remain pristine, unsullied by baser concerns such as the user interface or database used. Ideally, the code that represents the business rules should be the heart of the system, with lesser concerns being plugged in to them. The business rules should be the most independent and reusable code in the system. - “Clean Architecture: A Craftsman’s Guide to Software Structure and Design” [2] by Robert C. Martin, Chapter 20 “Business Rules”

However, on the other hand, he admits the existence of “Business Rules” in the context of the application’s operation:

Not all business rules are as pure as Entities. Some business rules make or save money for the business by defining and constraining the way that an automated system operates. These rules would not be used in a manual environment, because they make sense only as part of an automated system. - “Clean Architecture: A Craftsman’s Guide to Software Structure and Design” [2] by Robert C. Martin, Chapter 20 “Business Rules”

It’s not clear - “Business rules are the reason a software system exists” or “they make sense only as part of an automated system”?

There is a slight mutual exclusion here, and this is exactly the reason why I adhere to the wording of Eric Evans - “Application Layer does not contain business rules”.

It is clear that there is a lack of a term for expressing different things, and Robert Martin decides to differentiate the already existing term “Business Rules”, dividing it into two levels - “Critical Business Rules” and “Application-specific Business Rules”:

A use case is a description of the way that an automated system is used . It specifies the input to be provided by the user, the output to be returned to the user, and the processing steps involved in producing that output. A use case describes application-specific business rules as opposed to the Critical Business Rules within the Entities. - “Clean Architecture: A Craftsman’s Guide to Software Structure and Design” [2] by Robert C. Martin, Chapter 20 “Business Rules”

But then he reduces the responsibilities of the Use Case to those of the Application Logic, and emphasizes that the Use Case coordinates the “Critical Business Rules” implemented as Entities:

Use cases contain the rules that specify how and when the Critical Business Rules within the Entities are invoked. Use cases control the dance of the Entities. <...> Why are Entities high level and use cases lower level? Because use cases are specific to a single application and, therefore, are closer to the inputs and outputs of that system. Entities are generalizations that can be used in many different applications, so they are farther from the inputs and outputs of the system. Use cases depend on Entities; Entities do not depend on use cases. - “Clean Architecture: A Craftsman’s Guide to Software Structure and Design” [2] by Robert C. Martin, Chapter 20 “Business Rules”

Although, Robert Martin allocate the separate category UseCase (Interactor) classes for Application-specific Business Rules, in practice, this level is often rounded to Application Logic level. For example, Martin Fowler and Randy Stafford divide Business Logic into two types - Domain Logic and Application Logic:

Like Transaction Script (110) and Domain Model (116), Service Layer is a pattern for organizing business logic . Many designers, including me, like to divide “ business logic ” into two kinds: “domain logic,” having to do purely with the problem domain (such as strategies for calculating revenue recognition on a contract), and “application logic,” having to do with application responsibilities [Cockburn UC] (such as notifying contract administrators, and integrated applications, of revenue recognition calculations). Application logic is sometimes referred to as “workflow logic,” although different people have different interpretations of “workflow.” - “Patterns of Enterprise Application Architecture” [3] by Martin Fowler, Randy Stafford

In some places, he is inclined to refer “Business Rules” to Domain Logic:

The problem came with domain logic: business rules, validations, calculations, and the like. - “Patterns of Enterprise Application Architecture” [3] by Martin Fowler

And even he admits the presence of a certain vagueness:

Then there’s the matter of what comes under the term “business logic.” I find this a curious term because there are few things that are less logical than business logic. - “Patterns of Enterprise Application Architecture” [3] by Martin Fowler

Why is separation of Business Logic from Application Logic so important? ¶

Since the purpose of creating an application is precisely the implementation of Business Logic, it is important to ensure their portability and to separate them from the Application Logic. These two different kinds of rules will change at different times, at different rates, and for different reasons - so they should be separated so that they can be independently changed [2] . Grady Booch said that “Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change [2] .”

What is Service? ¶

SERVICE - An operation offered as an interface that stands alone in the model, with no encapsulated state. - “Domain-Driven Design: Tackling Complexity in the Heart of Software” [4]

In some cases, the clearest and most pragmatic design includes operations that do not conceptually belong to any object. Rather than force the issue, we can follow the natural contours of the problem space and include SERVICES explicitly in the model. There are important domain operations that can’t find a natural home in an ENTITY or VALUE OBJECT . Some of these are intrinsically activities or actions, not things, but since our modeling paradigm is objects, we try to fit them into objects anyway... A SERVICE is an operation offered as an interface that stands alone in the model, without encapsulating state, as ENTITIES and VALUE OBJECTS do. S ERVICES are a common pattern in technical frameworks, but they can also apply in the domain layer. The name service emphasizes the relationship with other objects. Unlike ENTITIES and VALUE OBJECTS , it is defined purely in terms of what it can do for a client. A SERVICE tends to be named for an activity, rather than an entity—a verb rather than a noun. A SERVICE can still have an abstract, intentional definition; it just has a different flavor than the definition of an object. A SERVICE should still have a defined responsibility, and that responsibility and the interface fulfilling it should be defined as part of the domain model. Operation names should come from the UBIQUITOUS LANGUAGE or be introduced into it. Parameters and results should be domain objects. SERVICES should be used judiciously and not allowed to strip the ENTITIES and VALUE OBJECTS of all their behavior. But when an operation is actually an important domain concept, a SERVICE forms a natural part of a MODEL-DRIVEN DESIGN . Declared in the model as a SERVICE, rather than as a phony object that doesn’t actually represent anything, the standalone operation will not mislead anyone. A good SERVICE has three characteristics. 1. The operation relates to a domain concept that is not a natural part of an ENTITY or VALUE OBJECT . 2. The interface is defined in terms of other elements of the domain model. 3. The operation is stateless. Statelessness here means that any client can use any instance of a particular SERVICE without regard to the instance’s individual history. The execution of a SERVICE will use information that is accessible globally, and may even change that global information (that is, it may have side effects). But the SERVICE does not hold state of its own that affects its own behavior, as most domain objects do. When a significant process or transformation in the domain is not a natural responsibility of an ENTITY or VALUE OBJECT, add an operation to the model as a standalone interface declared as a SERVICE. Define the interface in terms of the language of the model and make sure the operation name is part of the UBIQUITOUS LANGUAGE. Make the SERVICE stateless. - “Domain-Driven Design: Tackling Complexity in the Heart of Software” [4]

Service types by layers of logic ¶

Eric Evans divides Services into three layers of logic:

Partitioning Services into Layers Application Funds Transfer App Service Digests input (such as an XML request). Sends message to domain service for fulfillment. Listens for confirmation. Decides to send notification using infrastructure service. Domain Funds Transfer Domain Service Interacts with necessary Account and Ledger objects, making appropriate debits and credits. Supplies confirmation of result (transfer allowed or not, and so on). Infrastructure Send Notification Service Sends e-mails, letters, and other communications as directed by the application. - “Domain-Driven Design: Tackling Complexity in the Heart of Software” [4]

Most SERVICES discussed in the literature are purely technical and belong in the infrastructure layer. Domain and application SERVICES collaborate with these infrastructure SERVICES. For example, a bank might have an application that sends an e-mail to a customer when an account balance falls below a specific threshold. The interface that encapsulates the e-mail system, and perhaps alternate means of notification, is a SERVICE in the infrastructure layer. It can be harder to distinguish application SERVICES from domain SERVICES. The application layer is responsible for ordering the notification. The domain layer is responsible for determining if a threshold was met—though this task probably does not call for a SERVICE, because it would fit the responsibility of an “account” object. That banking application could be responsible for funds transfers. If a SERVICE were devised to make appropriate debits and credits for a funds transfer,that capability would belong in the domain layer. Funds transfer has a meaning in the banking domain language, and it involves fundamental business logic. Technical SERVICES should lack any business meaning at all. Many domain or application SERVICES are built on top of the populations of ENTITIES and VALUES, behaving like scripts that organize the potential of the domain to actually get something done. ENTITIES and VALUE OBJECTS are often too fine-grained to provide a convenient access to the capabilities of the domain layer. Here we encounter a very fine line between the domain layer and the application layer. For example, if the banking application can convert and export our transactions into a spreadsheet file for us to analyze, that export is an application SERVICE. There is no meaning of “file formats” in the domain of banking, and there are no business rules involved. On the other hand, a feature that can transfer funds from one account to another is a domain SERVICE because it embeds significant business rules (crediting and debiting the appropriate accounts, for example) and because a “funds transfer” is a meaningful banking term. In this case, the SERVICE does not do much on its own; it would ask the two Account objects to do most of the work. But to put the “transfer” operation on the Account object would be awkward, because the operation involves two accounts and some global rules. - “Domain-Driven Design: Tackling Complexity in the Heart of Software” [4]

Domain Models (116) are preferable to Transaction Scripts (110) for avoiding domain logic duplication and for managing complexity using classical design patterns. But putting application logic into pure domain object classes has a couple of undesirable consequences. First, domain object classes are less reusable across applications if they implement application-specific logic and depend on application-specific packages. Second, commingling both kinds of logic in the same classes makes it harder to reimplement the application logic in, say, a workflow tool if that should ever become desirable. For these reasons Service Layer factors each kind of business logic into a separate layer, yielding the usual benefits of layering and rendering the pure domain object classes more reusable from application to application. - “Patterns of Enterprise Application Architecture” [3]

Domain Service ¶

Higher-level policies belong to Domain Logic, so we start with it. Fortunately, this is not the most numerous type of Services.

In detail, the topic of Domain Services and the reasons for their existence are revealed Vaughn Vernon:

Further, don’t confuse a Domain Service with an Application Service. We don’t want to house business logic in an Application Service, but we do want business logic housed in a Domain Service. If you are confused about the difference, compare with Application. Briefly, to differentiate the two, an Application Service, being the natural client of the domain model, would normally be the client of a Domain Service. You’ll see that demonstrated later in the chapter. Just because a Domain Service has the word service in its name does not mean that it is required to be a coarse-grained, remote-capable, heavyweight transactional operation. ... You can use a Domain Service to Perform a significant business process Transform a domain object from one composition to another Calculate a Value requiring input from more than one domain object - “Implementing Domain-Driven Design” by Vaughn Vernon

Application Service ¶

This is the most numerous type of Services. Application Services are also known as Service Layer.

Infrastructure Service ¶

Infrastructure Service should be separate of other types of Service.

The infrastructure layer usually does not initiate action in the domain layer. Being “below” the domain layer, it should have no specific knowledge of the domain it is serving. Indeed, such technical capabilities are most often offered as SERVICES . For example, if an application needs to send an e-mail, some message-sending interface can be located in the infrastructure layer and the application layer elements can request the transmission of the message. This decoupling gives some extra versatility. The message-sending interface might be connected to an e-mail sender, a fax sender, or whatever else is available. But the main benefit is simplifying the application layer, keeping it narrowly focused on its job: knowing when to send a message, but not burdened with how. The application and domain layers call on the SERVICES provided by the infrastructure layer. When the scope of a SERVICE has been well chosen and its interface well designed, the caller can remain loosely coupled and uncomplicated by the elaborate behavior the SERVICE interface encapsulates. But not all infrastructure comes in the form of SERVICES callable from the higher layers. Some technical components are designed to directly support the basic functions of other layers (such as providing an abstract base class for all domain objects) and provide the mechanisms for them to relate (such as implementations of MVC and the like). Such an “architectural framework” has much more impact on the design of the other parts of the program. - “Domain-Driven Design: Tackling Complexity in the Heart of Software” [4]

Infrastructure Layer - Provides generic technical capabilities that support the higher layers: message sending for the application, persistence for the domain, drawing widgets for the UI, and so on. The infrastructure layer may also support the pattern of interactions between the four layers through an architectural framework. - “Domain-Driven Design: Tackling Complexity in the Heart of Software” [4]

Orchestration Service ¶

Orchestration Service is known as Service Layer and is cosidered in more detail below.

Choreography Service ¶

There is an interesting article “ Clarified CQRS ” by Udi Dahan, cited by Martin Fowler in his article “ CQRS ”.

And this article has an interesting point.

The reason you don’t see this layer explicitly represented in CQRS is that it isn’t really there... - “Clarified CQRS” by Udi Dahan

In fact, a command handler is a Service, but an event-driven one that follows a given interface. It should contain Application Logic (not Business Logic).

Our command processing objects in the various autonomous components actually make up our service layer. - “Clarified CQRS” by Udi Dahan

Choreography Services can only be at Application Logic, even if it is subscribed to a Domain Event.

Service types by communication ¶

By communication, Services are divided into Synchronous and Asynchronous.

Service types by state ¶

Stateless service ¶.

Typically, most Services are stateless. They are well known, and there is nothing to add.

Statefull Service ¶

The UseCases/Interactors [2] classes are a variation of the Command pattern, and can be considered as a Statefull Service.

Eric Evans has a similar idea:

We might like to create a Funds Transfer object to represent the two entries plus the rules and history around the transfer. But we are still left with calls to SERVICES in the interbank networks. What’s more, in most development systems, it is awkward to make a direct interface between a domain object and external resources. We can dress up such external SERVICES with a FACADE that takes inputs in terms of the model, perhaps returning a Funds Transfer object as its result. But whatever intermediaries we might have, and even though they don’t belong to us, those SERVICES are carrying out the domain responsibility of funds transfer. - “Domain-Driven Design: Tackling Complexity in the Heart of Software” [4]

And Randy Stafford with Martin Fowler too:

The two basic implementation variations are the domain facade approach and the operation script approach. In the domain facade approach a Service Layer is implemented as a set of thin facades over a Domain Model (116). The classes implementing the facades don’t implement any business logic. Rather, the Domain Model (116) implements all of the business logic. The thin facades establish a boundary and set of operations through which client layers interact with the application, exhibiting the defining characteristics of Service Layer. In the operation script approach a Service Layer is implemented as a set of thicker classes that directly implement application logic but delegate to encapsulated domain object classes for domain logic. The operations available to clients of a Service Layer are implemented as scripts, organized several to a class defining a subject area of related logic. Each such class forms an application “service,” and it’s common for service type names to end with “Service.” A Service Layer is comprised of these application service classes, which should extend a Layer Supertype (475), abstracting their responsibilities and common behaviors. - “Patterns of Enterprise Application Architecture” [3] by Martin Fowler, Randy Stafford

Notice, he used the term “ Domain Model ”. These guys are the last of those who can confuse “ Domain Model ” and “ DataMapper ”, especially with so many editors and reviewers. A client expects an interface from the domain model that it does not implement and should not implement for some reason (usually the Single Responsibility Principle). On the other hand, the client can not implement this behavior itself, as this would lead to “G14: Feature Envy” [1] . There is an Adapter (aka Wrapper) pattern for interface alignment, see “Design Patterns Elements of Reusable Object-Oriented Software” [6] . Statefull Service differs from the usual Adapter pattern only in that it contains lower-level logic, i.e. Application Logic, rather than Business Logic of Domain Model.

This approach reminds me of “Cross-Cutting Concerns” [1] , with the only difference being that “Cross-Cutting Concerns” implements the interface of the original object (delegate), while domain facade complements it. When a wrapper implements the interface of the original object, it is usually called Aspect or Decorator. Often in such cases the term Proxy is used, but, in fact, the Proxy pattern has a slightly different purpose. This approach is often used to provide the Domain Model with the logic of access to related objects, while keeping the Domain Model completely “clean”, i.e. separated from the behavior of lower level logic.

When I was working with legacy code, I saw swollen Domain Models with a huge number of methods (I met up to several hundred methods). If you analyze such models, you can often find extrinsical responsibilities in the class. As you know, size of a class is measured by amount of its responsibilities. Statefull Service and Adapter pattern are a good alternative to remove extrinsical responsibilities from a model and make swollen models lose weight.

When not to use Service Layer? ¶

The easier question to answer is probably when not to use it. You probably don’t need a Service Layer if your application’s business logic will only have one kind of client say, a user interface and its use case responses don’t involve multiple transactional resources. In this case your Page Controllers can manually control transactions and coordinate whatever response is required, perhaps delegating directly to the Data Source layer. But as soon as you envision a second kind of client, or a second transactional resource in use case responses, it pays to design in a Service Layer from the beginning. - “Patterns of Enterprise Application Architecture” [3]

However, the widely held view that access to the model should always be made through the Service Layer:

My preference is thus to have the thinnest Service Layer (133) you can, if you even need one. My usual approach is to assume that I don’t need one and only add it if it seems that the application needs it. However, I know many good designers who always use a Service Layer (133) with a fair bit of logic, so feel free to ignore me on this one. - “Patterns of Enterprise Application Architecture” [3]

The idea of splitting a services layer from a domain layer is based on a separation of workflow logic from pure domain logic. The services layer typically includes logic that’s particular to a single use case and also some communication with other infrastructures, such as messaging. Whether to have separate services and domain layers is a matter some debate. I tend to look as it as occasionally useful rather than mandatory, but designers I respect disagree with me on this. - “Patterns of Enterprise Application Architecture” [3]

Service is not a wrapper for Data Mapper ¶

Often Service Layer is mistakenly made in the for of wrapper over DataMapper . This is not quite the right decision. A Data Mapper serves a Domain Model, a Repository serves an Aggregate [9] , but a Service serves a client (or a client group). The Service Layer can manipulate multiple Data Mappers, Repositories, other Services within a business transaction and in favour of a client. Therefore, Service’s methods usually contain name of the returned Domain Model as a suffix (for example, getUser()), while methods of a Data Mapper (or a Repository) do not need such suffix (since the Domain name is already present in name of the Data Mapper class, and the Data Mapper serves only one Domain Model).

Identifying the operations needed on a Service Layer boundary is pretty straightforward. They’re determined by the needs of Service Layer clients, the most significant (and first) of which is typically a user interface. - “Patterns of Enterprise Application Architecture” [3]

Implementation of Service Layer ¶

There is a few examples of Service Layer implementations:

• https://github.com/in2it/zfdemo/blob/master/application/modules/user/services/User.php
• https://framework.zend.com/manual/2.4/en/in-depth-guide/services-and-servicemanager.html
• https://framework.zend.com/manual/2.4/en/user-guide/database-and-models.html#using-servicemanager-to-configure-the-table-gateway-and-inject-into-the-albumtable
• https://github.com/zendframework/zf2-tutorial/blob/master/module/Album/src/Album/Model/AlbumTable.php

Inversion of control ¶

Use Inversion of control, desirable in the form of Passive [1] “ Dependency Injection ” (DI).

True Dependency Injection goes one step further. The class takes no direct steps to resolve its dependencies; it is completely passive. Instead, it provides setter methods or constructor arguments (or both) that are used to inject the dependencies. During the con- struction process, the DI container instantiates the required objects (usually on demand) and uses the constructor arguments or setter methods provided to wire together the depen- dencies. Which dependent objects are actually used is specified through a configuration file or programmatically in a special-purpose construction module. “Clean Code: A Handbook of Agile Software Craftsmanship” [1]

One of the main responsibilities of Service Layer is the hiding of data source. It allows you to use Service Stub for testing. The same approach can be used for parallel development, when the implementation of the Service Layer is not ready yet. Sometimes it is useful to replace the Service with a fake data generator. In general, the Service Layer will be of little use if it is not possible to substitute it (or to substitute the dependencies used by it).

Widespread problem of Django applications ¶

A common mistake is to use the django.db.models.Manager class (and even django.db.models.Model) as a Service Layer. Often you can see how some method of the class django.db.models.Model takes as an argument the HTTP-request object django.http.request.HttpRequest, for example, to check the permissions.

The HTTP request object is the Application Layer logic, while the model class is the logic of the Domain Layer, i.e. objects of the real world, which are also called business rules. Checking permissions is also the logic of Application Layer.

The lower layer should not be aware of the higher layer. Domain-level logic should not be aware of application-level logic.

The class django.db.models.Manager corresponds most closely to the class Finder described in “Patterns of Enterprise Application Architecture” [3] .

With a Row Data Gateway you’re faced with the questions of where to put the find operations that generate this pattern. You can use static find methods, but they preclude polymorphism should you want to substitute different finder methods for different data sources. In this case it often makes sense to have separate finder objects so that each table in a relational database will have one finder class and one gateway class for the results. It’s often hard to tell the difference between a Row Data Gateway and an Active Record (160). The crux of the matter is whether there’s any domain logic present; if there is, you have an Active Record (160). A Row Data Gateway should contain only database access logic and no domain logic. - Chapter 10. “Data Source Architectural Patterns : Row Data Gateway”, “Patterns of Enterprise Application Architecture” [3]

Although Django does not use the Repository pattern, it uses an abstraction of the selection criteria in the form similar to the Query Object pattern. Like the Repository pattern, the model class ( ActiveRecord ) limits its interface using the Query Object interface. Clients should use the provided interface, rather than impose their responsibilities on the Model and its Manager on knowledge of their queries. And since class does not have to make assumptions about its clients, it is impossible to accumulate pre-defined queries in the Model class, because it can not be aware about the all needs of all clients. Clients should take care of themselves. But the Service Layer was created for client service. Therefore, it’s a responsibility of the Service Layer.

Attempts to exclude the Serving Layer from Django applications leads to the appearance of Managers with a lot of methods.

A good practice would be to hide the implementation (in the form of ActiveRecord ) of Django models by the Service Layer. This will allow painless ORM replace if necessary.

Some might also argue that the application logic responsibilities could be implemented in domain object methods, such as Contract.calculateRevenueRecognitions(), or even in the data source layer, thereby eliminating the need for a separate Service Layer. However, I find those allocations of responsibility undesirable for a number of reasons. First, domain object classes are less reusable across applications if they implement application-specific logic (and depend on application-specific Gateways (466), and the like). They should model the parts of the problem domain that are of interest to the application, which doesn’t mean all of application’s use case responsibilities. Second, encapsulating application logic in a “higher” layer dedicated to that purpose (which the data source layer isn’t) facilitates changing the implementation of that layer perhaps to use a workflow engine. - “Patterns of Enterprise Application Architecture” [3]

Problems of Django annotation ¶

I often observed the problem when a new field was added to the Django Model, and multiple problems started to occur, since this name was already used either with the annotation interface or with Raw-SQL. Also, the implementation of annotations by Django ORM makes it impossible to use the pattern Identity Map . Storm ORM / SQLAlchemy implement annotations more successfully. If you still had to work with Django Model, refrain from using Django annotation mechanism in favor of bare pattern DataMapper .

Peculiar properties of Service Layer on client side ¶

Using the Aggregate concept and reactive programming libraries, such as RxJS , allows us to implement Service Layer using a simplest pattern like Gateway , see, for example, the tutorial of Angular documentation . In this case, Query Object is usually implemented as a simple dictionary, which is then converted to a list of GET parameters for the URL. Such service usually communicates with a server either through JSON-RPC, or through REST-API Actions .

Everything works well until you need to express prioritized queries, for example, using the logical operator “OR” which has a lower priority than the logical operator “AND”. This raises the question of who should be responsible for building the query, the Service Layer of the client or the Service Layer of the server?

On the one hand, the server should not make assumptions about its clients, and must limit its interface through the interface Query Object . But this dramatically increases the level of complexity of the client, in particular, the implementation of Service Stub . To facilitate implementation, you can use the library rql mentioned in the article “ Implementation of Repository pattern for browser’s JavaScript ”.

On the other hand, the Service Layer, albeit a remote call, is designed to serve clients, so it can concentrate the logic of query building. If the client does not contain complex logic, allowing to interpret the prioritized queries for Service Stub, then no need to complicate it. In this case, it’s easier to add a new method to the remote call service, and get rid of the need for prioritized queries.

Concurrent update issue ¶

The advent of the Internet has provided access to a huge amount of data that is excessively large with the capabilities of the server. There was a need for scalability and distributed storage and processing of data.

One of the most acute problems is the concurrent update issue.

All race conditions, deadlock conditions, and concurrent update problems are due to mutable variables. You cannot have a race condition or a concurrent update problem if no variable is ever updated. You cannot have deadlocks without mutable locks. - “Clean Architecture: A Craftsman’s Guide to Software Structure and Design” [2] by Robert C. Martin

An order is a correct imposition of restrictions.

The concurrent update issue can be significantly reduced by restricting bidirectional state changes by introducing unidirectional changes, i.e. by separating reading from writing. This is exactly the approach used by Redux.

“it allows us to host the two services differently eg: we can host the read service on 25 servers and the write service on two. The processing of commands and queries is fundamentally asymmetrical, and scaling the services symmetrically does not make a lot of sense.” - “ CQRS, Task Based UIs, Event Sourcing agh! ” by Greg Young

Organizing Application Logic and Business Logic is well covered in the article “ Clarified CQRS ” by Udi Dahan.

The use of CQRS facilitates the use of Functional Programming paradigm.

For both theoretical and practical reasons detailed elsewhere [10], the command-query separation principle is a methodological rule, not a language feature, but all serious software developed in Eiffel observes it scrupulously, to great referential transparency advantage. Although other schools of object-oriented programming regrettable do not apply it (continuing instead the C style of calling functions rather than procedures to achieve changes), but in my view it is a key element of the object-oriented approach. It seems like a viable way to obtain the referential transparency goal of functional programming — since expressions, which only involve queries, will not change the state, and hence can be understood as in traditional mathematics or a functional language — while acknowledging, through the notion of command, the fundamental role of the concept of state in modeling systems and computations. - “Software architecture: object-oriented vs functional ” by Bertrand Meyer

Functional Programming inherently cannot produce side effects (since Functional Programming imposes a restriction on assignment (mutability)). This is the reason for its popularity growth in the era of distributed computing. No mutability - no concurrent update issues.

It is necessary to distinguish the Functional Programming paradigm from the languages supporting this paradigm, since quite often the languages supporting this paradigm allow not to follow it.

However, despite the new opportunities to use Functional Programming in code, the data storage itself (IO device) is still prone to the concurrent update issues, since it has mutable rows, and, therefore, has a side effect.

The solution to this problem is usually to replace CRUD (Create, Read, Update, Delete) with CR, i.e. imposing restrictions on Update and Delete rows in the storage, that is widespread with the name Event Sourcing. There are specialized storages that implement Event Sourcing, but it can also be implemented without specialized tools.

Event Sourcing ¶

If CQRS allows working with data storages in the Imperative style, and separates a command (side effect) from a query (reading) data, then Event Sourcing goes even further and imposes a restriction on changing and deleting data, turning CRUD into CR. This pattern allows working with data storages in the Functional style, and provides the same benefits: no mutable state - no concurrent update issues. And the same disadvantages - high memory and processor consumption. This is the reason why this pattern is widely used in distributed systems, where there is an acute need for its advantages, and at the same time, its weaknesses do not appear (since distributed systems are not limited either in memory or in processor power).

A good example of Event Sourcing can be the principle of organizing a bank account in a database, when the account is not a source of truth, but simply reflects the aggregate value of all transactions (i.e. events).

This topic is well covered in Chapter 6 “Functional Programming” of “Clean Architecture” by Robert C. Martin.

More importantly, nothing ever gets deleted or updated from such a data store. As a consequence, our applications are not CRUD; they are just CR. Also, because neither updates nor deletions occur in the data store, there cannot be any concurrent update issues. If we have enough storage and enough processor power, we can make our applications entirely immutable—and, therefore, entirely functional . If this still sounds absurd, it might help if you remembered that this is precisely the way your source code control system works. - “Clean Architecture: A Craftsman’s Guide to Software Structure and Design” [2] by Robert C. Martin

Event Sourcing is naturally functional. It’s an append only log of facts that have happened in the past. You can say that any projection any state is a left fold over your previous history. - Greg Young, “ A Decade of DDD, CQRS, Event Sourcing ” at 16:44

It’s actually functional. - Greg Young, “ Event Sourcing is actually just functional code ” at 34:49

I have always said that Event Sourcing is “Functional Data Storage”. In this talk we will try migrating to a idiomatic functional way of looking at Event Sourcing. Come and watch all the code disappear! By the time you leave you will never want an “Event Sourcing Framework (TM)” ever again! - Greg Young, “ Functional Data ”, NDC Conferences

@emacsway's blog

Jul 17, 2017.

• Oct 12, 2019
• Ivan Zakrevsky
• Software Design , Software Architecture , ORM , Django Model , Service Layer , Redux , Flux , Model , CQRS , Event Sourcing

Quick search

Stack Exchange Network

Stack Exchange network consists of 183 Q&A communities including Stack Overflow , the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

Where does authorization fit in a layered architecture?

Typically, I place authorization decisions in my server side controllers. These have been RESTful endpoints recently, but I think the same stands for MVC type architectures. For the sake of argument assume that it's role based authorisation. A protected method will be annotated or make checks and return 403s if necessary.

Now, given that authorisation is in fact a business rule - "only administrators can list X" for example, I'm thinking they should be pushed down a layer. When a controller asks the business layer to perform the operation, the service or business layer informs the controller it's not authorised.

Is this a reasonable approach? Are there disadvantages to this?

I'm loathe to have an AuthorisationService that essentially holds a bunch of static procedural coded rules to do this but maybe it makes sense to keep all access logic in one place. Is it a cross cutting concern that should be kept separate?

So I'm asking if anyone has done this and how they achieved it in a clean way or if there are any good resources I could read. I'm using Java fwiw but this is a language agnostic question.

I've checked out the related questions on here and they're very thin on the ground and answers. For example: Validation and Authorisation in Domain Models and Carrying that through a Service Layer to MVC

I'm reading the spring security docs which make some good arguments for it being a cross cutting concern, but I'm worried it's just the "spring way" and would like wider perspectives. It also ties your application to a specific framework.

• architecture

• 1 Status 403 is wrong for authorisation problems. Use 401. –  gnasher729 Commented Oct 31, 2015 at 20:43
• 3 @gnasher729 I think that's backwards. 401 means authentication has failed or is not provided, 403 means you don't have access rights: stackoverflow.com/questions/3297048/… –  JimmyJames Commented May 31, 2019 at 15:51
• 1 @JimmyJames, there's another school of thought that you should just use only one of them for all authentication and authorization failures since it doesn't let automated tools infer business logic as easily. There's some leeway. –  Berin Loritsch Commented May 31, 2019 at 18:00
• 4 @BerinLoritsch Sorry, are you saying that the idea is to make it harder to understand if it's an authentication or authorization issue? The RFC seems pretty clear but states you can use 404 instead of 403 if you don't want to expose too much info. Is there a reference you can provide for the argument for using a 401 instead of 403? –  JimmyJames Commented May 31, 2019 at 18:13
• 1 @JimmyJames, Yes. This thought process comes from security professionals, not developers. And I've also seen your recommendation of 404 to completely hide the information to hide that the resource even exists. –  Berin Loritsch Commented May 31, 2019 at 19:27

4 Answers 4

Its good practice to expose only the options a user is authorized for.

This forces authorization to be a cross cutting concern. The "View" needs to know what a user is allowed to do before it can build options and menus for display.

The back end should not trust the front end to make security decisions so must check authorization itself.

There may be business rules that effect authorization depending on data e.g. "Only users with a balance over $5000 can invoke a foreign currency transfer" or "Only a user located at Head Office can view these accounts". So some authorization logic is required within the the business logic.

There are also Technical authorizations to consider - who is allowed to view the logs, who can backup/restore the database etc.

So in the end every component in your may have some specific security and/or authorization requirements, in practice its almost impossible to wrap this up into a separate "authorization layer".

• Is "user" correct term here? What if user is bank advisor/operator, which has got balance over 5000, can the user then execute transfer for customer with balance less than 5000? –  kravemir Commented Jan 16, 2020 at 8:16

I like pushing authorization checks down as low as they can go! (But no further!)

You're still free to write automated authorization tests against layers "above" this. And some rules may only be applicable or make sense in higher layers like your service layer (CanView/CanSerialize?). But, I generally think the safest authorization strategy is also "DRY-est" strategy: Keep authorization as low as possible, in the most "common" or "shared" code as you can (without over-complicating the auth rules).

Think about the alternative. If your authorization rules are tested and enforced only in the service layer, leaving your poor domain objects to bend to the wills of a moody service objects, you'll often be required to enforce each individual rule more than once, in multiple objects and multiple places in each object, and in more complicated code.

Furthermore, when your analytics team hires a consulting firm to write reporting services using your domain objects, you don't want to have to trust those developers! (Or whatever. You build additional services or calls over the same objects for any reason.) You won't want to crack open the big book of business rules and hope to enforce those rules properly again ; you want your domain to already know them and enforce them.

• @Shoe If I understand your concern -- that's sort of the point. If only an "admin" has permission, per the business rules, to create a Widget , the same rule applies everywhere. (So don't risk letting anyone ignore it!) If the rule doesn't apply everywhere, it's not really a rule about Widgets and only Widgets . . Push rules down as far as they (the individual rule(s)) can go; but, not as far as "rules" can go ... I feel like I'm not stating the distinction well. But, there's supposed to be distinction there. –  svidgen Commented Jul 2, 2018 at 20:07
• In my experience, authorization rules are often part of the business rules. As such, "as far down as they can go" is often my domain layer. But, I suspect that where your rules "should" fall is just a consequence of your domain, the nature of the rules, and how the business talks about them. –  svidgen Commented Jul 2, 2018 at 20:17

I think it's absolutely reasonable approach to engrain authorization in your Service layer. You need to protect your service from performing unauthorized activities(especially data-modifications). Your Service layer could resides in one library, and being used by different Presentation layers(you could have different UI-applications, that use the same Service layer). And you can't rely on the fact that specific Presentation layers perform necessary validation. This is especially important if you will decide afterwards to move your Service layer to the separate process(e.g. following SOA approach).

Now about how to achieve this in a "clean way". I don't like the idea of littering business logic with authorization checks, so some specific implementation of aspect-oriented-programming-approach could help: it could be decorating service methods with special attributes or using dynamic proxies with interceptions.

And importantly, I need to admit that in very simple projects, may be, you could live without separated validations, just to simplify your life. But it's important do not miss the moment when "simple project" began to become "complex project".

It is the most likely a good approach to push authorization checks out of controllers . Controllers are just one of many possible implementation parts in presentation layer for given application.

If you implement alternative API in presentation layer, then you need to locate existing corresponding security checks in existing controllers, and duplicate them - not DRY. This approach is prone to errors, and doesn't deliver high confidence regarding security and enforcement of rules.

To have high confidence in security and reliability, then presentation layer should use only secured interfaces for application's data and business logic.

I like following drawing of hexagonal architecture from article DDD, Hexagonal, Onion, Clean, CQRS, … How I put it all together :

In this high level view of the whole system it's visible, there are parts (APIs) of multiple different frontends to the application. Therefore controllers should be as thin layer as possible, and be doing only bare minimum to provide access to application in required form.

Your Answer

Reminder: Answers generated by artificial intelligence tools are not allowed on Software Engineering Stack Exchange. Learn more

Sign up or log in

Post as a guest.

Required, but never shown

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy .

Not the answer you're looking for? Browse other questions tagged architecture or ask your own question .

• The Overflow Blog
• Ryan Dahl explains why Deno had to evolve with version 2.0
• From PHP to JavaScript to Kubernetes: how one backend engineer evolved over time
• Featured on Meta
• We've made changes to our Terms of Service & Privacy Policy - July 2024
• Bringing clarity to status tag usage on meta sites

Hot Network Questions

• Non decreasing function for utility transformation
• Visualizing histogram of data on unit circle?
• What's the counterpart to "spheroid" for a circle? There's no "circoid"
• Op Amp Feedback Resistors
• Why don't we observe protons deflecting in J.J. Thomson's experiment?
• How did the cop infer from Uncle Aaron's statement that Miles has been visiting?
• How to raise a vector to powers contained in a vector, change the list into a product, and do this for all the lines of a matrix, efficiently?
• What's the difference between "nah" and "nahe"?
• How does quantum field theory affect the ontological tenability of composite objects?
• What sort of impact did the discovery that water could be broken down (via electrolysis) into gas have?
• What (if any) pre-breathes were "attempted" on the ISS, and why?
• C - mini string lib
• Can figere come with a dative?
• Matrix with \guilsinglright, \guilsinglleft and \textlquill, \textrquill
• How to determine if a set is countable or uncountable?
• Does gluing two points prevent simple connectedness?
• Are there any original heat shield tiles on any of the retired space shuttles that flew to space?
• Are chord inversions determined solely by the lowest note, even in a broken chord?
• Looking for title of a Ursula K. Le Guin story/novel that features four-way marriage/romantic relationships
• Chord definition misunderstanding
• If the Collatz conjecture is undecidable, then it is true
• Why do combinatorists care about Kazhdan–Lusztig polynomials?
• Fast circular buffer
• Would it take less thrust overall to put an object into higher orbit?

St.Petersburg

Aug 14, 2014

340 likes | 574 Views

St.Petersburg. 1703 – 2003 300th Anniversary. History and features of St.Petersburg. Established on May 27, 1703 by Peter I (Peter the Great) as a “Window to Europe” “Northern Venice” – about 100 islands and 200 bridges 1712 – 1918 – the Capital of Russia 1917 - October Revolution

Share Presentation

• white nights
• northern venice
• anichkov bridge
• 300th anniversary
• russian museum

Presentation Transcript

St.Petersburg 1703 – 2003 300th Anniversary

History and features of St.Petersburg • Established on May 27, 1703 by Peter I (Peter the Great) as a “Window to Europe” • “Northern Venice” – about 100 islands and 200 bridges • 1712 – 1918 – the Capital of Russia • 1917 - October Revolution • 1924 – 1991 – Leningrad • 1941 – 1943 – Blockade of Leningrad • “Cultural capital of Russia” • About 5 million people • More than 50 universities

Peter and Paul's Fortress

Summer Garden

The Bronze Horseman

Canals of St.Petersburg

The Winter Canal

Anichkov Bridge

White Nights in St.Petersburg

The Hermitage (Winter Palace)

General Headquarters

The Russian Museum

Mikhailovsky Castle

Savior on the Spilt Blood Cathedral

The Kazan Cathedral

St. Isaac's Cathedral

The Smolny Convent

Peterhof (Petrodvorets)

Peterhof – Upper Garden

Peterhof - Interior

Tsarskoye Selo (Pushkin)

Pavlovsk – Interior

Mariinsky Theater

St.Petersburg State Polytechnic University

• More by User

IT Personnel in St.Petersburg

IT Personnel in St.Petersburg. St.Peter market and Investors St.Peter IT market (people:” sources &amp; customers”) T endencies . IT Personnel in St.Petersburg. St.Peter market and Investors Is attractive as in previous years: new -Toyota, IKEA, Siemens, Elcoteq , Nissan, Nokian Tyrers, etc…

207 views • 7 slides

St.Petersburg 22.06.2018 CEO Rolf Fiskerstrand

COORPERATION WITH NORWEGIAN MARITIME INDUSTRY. Design Equipment Construction Export Financing. St.Petersburg 22.06.2018 CEO Rolf Fiskerstrand. FISKERSTRAND HOLDING AS. DESIGN - DOCKING - CONVERSION - REPAIR - MAINTENANCE - SHIPBUILDING. FISKERSTRAND HOLDING AS.

269 views • 14 slides

CASUALTIES AT SEA : REALISTIC OVERVIEW St.Petersburg 2009

CASUALTIES AT SEA : REALISTIC OVERVIEW St.Petersburg 2009. CASUALTIES AT SEA: REALISTIC OVERVIEW. Casualties result not only in significant losses of shipowners , cargo owners , underwriters , not only in human tragedies , but also lead to global consequences of the ecological nature.

271 views • 15 slides

St.Petersburg.

319 views • 23 slides

Vasily Smolyanitsky Arctic and Antarctic Research Institute, St.Petersburg Russia

Sea ice in GCW Cryonet (interaction with sea-ice community). Vasily Smolyanitsky Arctic and Antarctic Research Institute, St.Petersburg Russia WMO-IOC JCOMM Expert Team on Sea Ice (ETSI), chair. CryoNet Team Meeting First Session Reykjavik , Iceland 20-22 January 2014.

228 views • 12 slides

V.V. Chaldyshev , A.S. Shkolnik, V.P. Evtikhiev, Ioffe Institute, St.Petersburg, Russia,

Optical spectroscopy of a semi-insulating GaAs/AlGaAs multiple quantum well system near double exciton-polariton and Bragg resonance. V.V. Chaldyshev , A.S. Shkolnik, V.P. Evtikhiev, Ioffe Institute, St.Petersburg, Russia, T. Holden Brooklyn College of the City University of New York, USA.

339 views • 18 slides

St.Petersburg National Research University of Information Technologies, Mechanics and Optics

St.Petersburg National Research University of Information Technologies, Mechanics and Optics. Strategic Areas of Cooperation with Dutch Universities. Vladimir Vasilyev. 12.04.2013. Basic Information. Undergraduate students 13 500 Graduate students 2 000

405 views • 24 slides

St.Petersburg in Russian Politics

St.Petersburg in Russian Politics. 1991, June - Mayor’s elections Anatoly Sobchack. 1996, May –Governor’s Elections. Vladimir Yakovlev St.Petersburg Governor 1996-2003. GOVERNOR’S ELECTIONS 2003. Valentina Matveenko versus Anna Markova

147 views • 7 slides

Possible (St.Petersburg) scenarios for LHC data analysis

Possible (St.Petersburg) scenarios for LHC data analysis. Valuable fraction of the data analysis will be done at PNPI and around (it means PNPI has to behave as St.Petersburg regional leader); only PNPI computing facility will be used for the analysis;

196 views • 10 slides

SHORT OVERVIEW OF MEDICAL GRIDS G.Feofilov NGN-4 meeting, St.Petersburg 20.05.05

SHORT OVERVIEW OF MEDICAL GRIDS G.Feofilov NGN-4 meeting, St.Petersburg 20.05.05. CONTENTS Introduction PACS HEALTHGRID MAMMOGRID GPCALMA PLANS istc #2887? CONCLUSIONS. Motivation. WWW - was invented in 1992 at CERN

517 views • 39 slides

Partnership “South-East Finland – St.Petersburg and Leningrad oblast”

South-East Finland – Russia ENPI CBC 2007-2013. Partnership “South-East Finland – St.Petersburg and Leningrad oblast” Georgy Psarev, Senior Expert, SPb Branch of JMA ENPI “South East Finland – Russia” Sankt-Petersburg, 19 th of October 2010. Joint territory as an Unique Selling Point.

595 views • 40 slides

St.Petersburg. Salchak Ochur 5 B English teacher Zarina Aldyn-oolovna. The fountains. Smolniy Monastery. The Peterhof. Water Avenue. The gothic kapella. The fountain The Golden Mountain. Kazan cathedral. Book House. Lion’s cascade. Petropavlovsk Cathedral. Pyramid Fountain.

287 views • 16 slides

Talk at HSQCD 2004, Repino, St.Petersburg, Russia 18-22 May 2004

Observation of narrow exotic baryon resonance by the SVD-2 experiment in pA interactions at 70 GeV/c A.Kubarovsky, V.Popov SINP MSU Moscow (for SVD collaboration). Talk at HSQCD 2004, Repino, St.Petersburg, Russia 18-22 May 2004. K -. .  . .  . P-beam. K -. .  .  . 1.a.

240 views • 16 slides

2007 World Ch ampionship in St.Petersburg

2007 World Ch ampionship in St.Petersburg. Radiance Nobleness Sophistication. Epee, sirs, is a mystic creature. Yes-yes, fencing is a mystics for noble people. Especially nowadays. Sir Elton John. résonner passion. Clink i ng Passion.

196 views • 9 slides

Tatiana Khvatova St.Petersburg State Polytechnic University 2008

Russia’s National System of Innovation: strengths and weaknesses Studying the business sector of Russia’s NSI. Tatiana Khvatova St.Petersburg State Polytechnic University 2008. Russia’s NSI indicators 2007. Global Summary Innovation index (25 th out of 49)

391 views • 26 slides

THE SYSTEM OF HIGHER EDUCATION RUSSIA . ST.PETERSBURG

THE SYSTEM OF HIGHER EDUCATION RUSSIA . ST.PETERSBURG. PROFESSIONAL HIGHER EDUCATION IN RUSSIAN FEDERATION. Higher education. Professional higher education is governed by the Ministry of Education and Science of Russian Federation . There are three types of higher education:

483 views • 17 slides

Attractive Balloon Shades for Decoration in St.petersburg

The Blind Shack is a leading company selling quality balloon shades in St.petersburg. They are the family owned and operated business working hard to provide the customer needs. Balloon shades are made up of fabrics used for decoration purpose in hotels and homes. These shades are same as the Roman shades but much softer in the bottom. They also provide free home consultation service. For more details about us visit at https://theblindshackcf.com/services/balloon-shades/

88 views • 7 slides

Alexander Klepikov Arctic &amp; Antarctic Research Institute of Roshydromet ( AARI) St.Petersburg

AARI ACTIVITIES IN COLD REGIONS. Alexander Klepikov Arctic &amp; Antarctic Research Institute of Roshydromet ( AARI) St.Petersburg. Reinforcing the Development and Implementation of the GEO Cold Regions Initiative (GEOCRI) GEO-XIII, St.Petersburg, Russian Federation 8 November 2016.

254 views • 21 slides

Training centre EDUPOLI in St.Petersburg

Training centre EDUPOLI in St.Petersburg. From the beginning…. 10 years ago Quality management assessment Up-grading qualification of Russian educational staff International projects Students and teachers exchanges Conferences and seminars. OPENING CEREMONY. OPENNING CEREMONY 31/08/10.

104 views • 9 slides

289 views • 28 slides

Implementation of advanced technical solutions of St.Petersburg Vodokanal in the city

European Economic Congress Katowice, 14-16 May Water supply system and water management. Implementation of advanced technical solutions of St.Petersburg Vodokanal in the city. Vladimir Gvozdev Deputy Head of Water Supply Department, Engineering and Innovation Center

161 views • 15 slides

Large-scale RF mesh AMR implementation (experience in St.Petersburg)

Large-scale RF mesh AMR implementation (experience in St.Petersburg). Sergey Khudyakov Data Transfer, Inc. Russia. AMR drivers. Non-technical loss elimination Reduce theft Increase payment control Technical loss elimination Transformer loss monitoring Transmission loss monitoring

208 views • 20 slides

• Stack Overflow for Teams Where developers & technologists share private knowledge with coworkers
• Advertising & Talent Reach devs & technologists worldwide about your product, service or employer brand
• OverflowAI GenAI features for Teams
• OverflowAPI Train & fine-tune LLMs
• Labs The future of collective knowledge sharing
• About the company Visit the blog

Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

Get early access and see previews of new features.

Presentation layer / Public Services layer. A common term?

While defining our application architecture (which contains both web UI and external web services) we stumbled upon our inability to find a common name for the topmost layer. It is quite clear that there are DAL (data access layer) and BLL (business logic layer) in our application. On the top of BLL, there reside the UI, which is commonly called the presentation layer (e.g., http://msdn.microsoft.com/en-us/library/ff647339.aspx ). But there's also a service layer, which resides on the top of BLL as well!

But a cake can't have two layers on the same level :) So please help me to find a term for that.

• architecture
• nomenclature
• presentation-layer
• service-layer

3 Answers 3

The term API (Application Programming Interface) is commonly used for programming interfaces, though in this case "Service Layer" may be more appropriate and descriptive.

Layers can be side by side - nothing says they have to be one on top of another.

• API and "Service Layer" can be terms for web services. But what about the UI part? I'd like to have a common term. And in my world layers have to be on the top of each other. Service layer and web presentation are in one layer, at least in my opinion. –  Dmytro Shevchenko Commented Sep 1, 2010 at 14:58
• @Shedal - If you can see it and interact with it, it belongs to the Presentation Layer. –  Oded Commented Sep 1, 2010 at 15:01

Presentation Layer is the one I've heard most for the layer containing UI components.

• Yes, but what about a common term for Ui and services? –  Dmytro Shevchenko Commented Sep 1, 2010 at 14:56

What about Outer Layer? Top Layer? The Layer-that-shall-not-be-named?

Your Answer

Reminder: Answers generated by artificial intelligence tools are not allowed on Stack Overflow. Learn more

Sign up or log in

Post as a guest.

Required, but never shown

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy .

Not the answer you're looking for? Browse other questions tagged architecture layer nomenclature presentation-layer service-layer or ask your own question .

• The Overflow Blog
• Ryan Dahl explains why Deno had to evolve with version 2.0
• From PHP to JavaScript to Kubernetes: how one backend engineer evolved over time
• Featured on Meta
• We've made changes to our Terms of Service & Privacy Policy - July 2024
• Bringing clarity to status tag usage on meta sites
• Feedback requested: How do you use tag hover descriptions for curating and do...
• What does a new user need in a homepage experience on Stack Overflow?

Hot Network Questions

• How should I respond to a former student from my old institution asking for a reference?
• Thai word not breaking properly between lines, in LuaLaTeX
• Which translation of Psalm 113:9 is closest to the original?
• 2024 Taiwan Payment Modality
• When a submarine blows its ballast and rises, where did the energy for the ascent come from?
• Why if gravity would be higher, designing a fully reusable rocket would be impossible?
• Are chord inversions determined solely by the lowest note, even in a broken chord?
• How can I address my colleague communicating with us via chatGPT?
• What does 北渐 mean?
• Are there any virtues in virtue ethics that cannot be plausibly grounded in more fundamental utilitarian principles?
• How do I do calculations with a sliding window while being memory-efficient?
• Print tree of uninstalled dependencies and their filesizes for apt packages
• How does quantum field theory affect the ontological tenability of composite objects?
• Fitting 10 pieces of pizza in a box
• Are automorphisms of matrix algebras necessarily determinant preservers?
• What sort of impact did the discovery that water could be broken down (via electrolysis) into gas have?
• xwininfo: what is "depth"?
• Is there anything that stops the majority shareholder(s) from destroying company value?
• How to extract code into library allowing changes without workflow overhead
• Does gluing two points prevent simple connectedness?
• What (if any) pre-breathes were "attempted" on the ISS, and why?
• Version of Dracula (Bram Stoker)
• If you get pulled for secondary inspection at immigration, missing flight, will the airline rebook you?
• What's the counterpart to "spheroid" for a circle? There's no "circoid"

You are using an outdated browser. Please upgrade your browser or activate Google Chrome Frame to improve your experience.

• Saint Petersburg

St Pete Limo Service

• Phone 727-308-6463
• www.stpetelimoservice.com

About St Pete Limo Service

• Write A Recommendation

How to watch ‘Forever: A Terry McMillan Presentation’ (for free)

• Published: Aug. 24, 2024, 2:40 p.m.

• Joseph Rejent | NJ Advance Media for NJ.com

“ Forever: A Terry McMillan Presentation ″ is airing for the first time on Lifetime on Saturday, Aug. 24 at 8 p.m. You can watch live as it airs on DIRECTV Stream (free trial) or Philo (free trial) .

The special will tell the story of a veteran trying to impress a local policewoman, but he faces a significant challenge: her three daughters.

Here’s the information you’ll need to watch a free live stream of “Forever: A Terry McMillan Presentation″ online without cable.

How to watch ‘Forever: A Terry McMillan Presentation′ without cable

If you’re a cord-cutter or don’t have cable, you can live stream “Forever: A Terry McMillan Presentation″ on any one of the following streaming services:

DIRECTV Stream (free trial)

In addition to ABC, Freeform, ESPN, and the other Disney channels, DIRECTV Stream offers CBS, NBC, and FOX. This sets it apart from most live TV streaming services. On top of that, a subscription gets you access to more than 65 other channels in its base package, including Nickelodeon, MTV, CNN, vh1, and more. The biggest selling point for DIRECTV Stream , however, is that it is the best for live and regional sports coverage. Add that to over 65,000 on-demand titles and its Cloud DVR and you have a diverse, versatile service that can meet any of your streaming needs. The base package costs $64.99 per month, with a wide range of add-on options. DIRECTV Stream offers a five-day free trial .

Philo (free trial)

Philo is remarkably inexpensive for the amount of content it offers, with more than 70 live channels, the ability to stream from three devices simultaneously and a 365-day DVR with unlimited space. Subscribers will also have access to thousands of movies and TV series on-demand. The service costs $25 per month. There are several available packages that include premium channels, like Epix and Starz, for an additional cost. The service offers a seven-day free trial that includes all the features of full subscription.

When is ‘Forever: A Terry McMillan Presentation′ on?

“Forever: A Terry McMillan Presentation″ premieres on Saturday, Aug. 24 at 8 p.m. on Lifetime. The special will be followed by a repeat of an older movie.

What channel is Lifetime?

You can use the channel finder on your provider’s website to locate it: Verizon Fios , AT&T U-verse , Comcast Xfinity , Spectrum/Charter , Optimum/Altice , DIRECTV , Dish .

How to watch ‘Forever: A Terry McMillan Presentation′ online on-demand

If you missed “Forever: A Terry McMillan Presentation″ or want to watch the movie online when it becomes available, check out DIRECTV Stream (free trial) or Philo (free trial) .

How to watch ‘Forever: A Terry McMillan Presentation’ if you’re not in the USA

If you’re not in the USA, you can still use a VPN to sign up for Philo or DIRECTV Stream and set your location to a US server.

Among the safest choices to use are ExpressVPN or NordVPN . Both services offer massive discounts, along with a 100% money-back guarantee within the first 30 days.

What is ‘Forever: A Terry McMillan Presentation′ about?

According to the official description of the TV special : A veteran falls head over heels for a local policewoman after returning to his hometown. However, to win her heart, he must also win the approval of her three teenage daughters.

Here’s a look at another Lifetime special, courtesy of the Lifetime official YouTube channel:

Related stories about streaming TV services

More streaming service stories.

• The best VPNs of 2023, according to reviews
• What is Sling TV and how does it work? Price, channels, live streaming info
• Forget Netflix. Apple TV+ is the streaming service you need right now.
• How to watch ‘Yellowstone,’ the hottest show on TV right now

Our journalism needs your support. Please subscribe today to NJ.com .

Joseph Rejent covers TV, writing about live television, streaming services and cord-cutting. He can be reached at [email protected] .

If you purchase a product or register for an account through a link on our site, we may receive compensation. By using this site, you consent to our User Agreement and agree that your clicks, interactions, and personal information may be collected, recorded, and/or stored by us and social media and other third-party partners in accordance with our Privacy Policy.