Understanding the Logical View: Abstracting What a System Does

What is the Logical View?

The logical view is the first view of the 4+1 view model. It answers “what does the system do?” and describes the system from a functional perspective, focusing on capabilities offered to users rather than implementation details.

Logical View vs. Other Views

Logical view – functional (e.g., rooms in a house).

Development view – code organization (how rooms are decorated).

Process view – runtime (how the house operates).

Physical view – deployment (where the house is built).

Core Elements of the Logical View

Module

A module is the basic unit representing a functional block.

Responsibilities

Clearly define what the module is responsible for.

State what the module does not handle.

Naming

Use business terminology, noun names, clear and understandable.

Relationships Between Modules

Dependency

┌─────────┐       ┌─────────┐
│  User   │──────►│ Order   │
└─────────┘       └─────────┘
(Order module depends on User module)

Containment

┌─────────────────┐
│ User Center     │
├─────────────────┤
│ ┌─────────────┐ │
│ │ Auth        │ │
│ └─────────────┘ │
│ ┌─────────────┐ │
│ │ Info        │ │
│ └─────────────┘ │
└─────────────────┘
(User Center contains Auth and Info sub‑modules)

Inheritance

┌─────┐
     │User │
     └─┬───┘
       ▼
 ┌───────┐   ┌───────┐
 │Admin  │   │Normal │
 │User   │   │User   │
 └───────┘   └───────┘
(Admin and Normal User inherit from User)

Core Principles

High cohesion

Elements inside a module should be closely related and jointly fulfill a single responsibility.

Low coupling

Modules should have few dependencies and dependency relationships should be simple.

How to Draw a Logical View

Step 1 – Identify System Boundaries

┌─────────────────────────────────────┐
│          E‑commerce System          │
│  ┌───────┐  ┌───────┐  ┌───────┐   │
│  │User   │  │Product│  │Order │   │
│  └───────┘  └───────┘  └───────┘   │
└─────────────────────────────────────┘
External systems: third‑party payment, logistics, SMS gateway, data sources.

Step 2 – Identify Core Modules

E‑commerce System
├── User Domain
│   ├── Authentication
│   ├── Registration
│   ├── User Info
│   └── Permissions
├── Product Domain
│   ├── Product Management
│   ├── Product Search
│   ├── Category Management
│   └── Review Management
├── Order Domain
│   ├── Place Order
│   ├── Payment
│   ├── Logistics
│   └── After‑sale
└── Marketing Domain
    ├── Coupons
    ├── Campaigns
    └── Points

Step 3 – Define Module Responsibilities

Module      Responsibility                     External API
User        User registration, login, profile   /api/user/*
Auth        Authentication, token management    /api/auth/*
Product     Product CRUD and search             /api/product/*
Order       Order flow management                /api/order/*

Step 4 – Draw the Logical Architecture Diagram

┌─────────────────────────────────────────────────────┐
│                E‑commerce System                     │
├─────────────────────────────────────────────────────┤
│  User Module   Product Module   Order Module          │
│  ┌─────┐      ┌─────┐          ┌─────┐               │
│  │Auth │      │Search│          │Place│               │
│  └─────┘      └─────┘          └─────┘               │
│  │Perm │      │Manage│          │Pay  │               │
│  └─────┘      └─────┘          └─────┘               │
│      │           │               │                  │
│      └───────────┼───────────────┘                  │
│                  │                                 │
│            ┌─────▼─────┐                           │
│            │ Data Access│                         │
│            └───────────┘                           │
└─────────────────────────────────────────────────────┘

Expression Methods

Layered Architecture

┌───────────────────────┐
│ Presentation Layer     │
│ (Controllers, API, UI)│
├───────────────────────┤
│ Business Logic Layer  │
│ (Services, Logic)     │
├───────────────────────┤
│ Data Access Layer     │
│ (Repositories, DAOs)  │
├───────────────────────┤
│ Infrastructure Layer  │
│ (Database, Cache, MQ)│
└───────────────────────┘

Domain Model

Domain Layer
 ├─ User   (-name, -email)
 └─ Order  (-id, -items)
        │
        ▼
      OrderItem (-productId, -quantity, -price)

Service‑Oriented

Service Gateway
   │
 ┌─┴─┐
 │User Service   │Product Service│
 └─┬─┘               └─┬─┘
   │                     │
   └────── Shared Data Layer (User, Product, Order data)

Common Pitfalls

Do not treat implementation technology (e.g., Redis cache) as a functional module; classify by business capability such as “Product Search”.

Avoid over‑granular division (one class per module); aggregate by business capability.

Do not ignore cross‑module collaboration; explicitly describe interactions.

Logical View Documentation Template

# Logical View Document

## 1. System Overview
[Brief description of core functions]

## 2. Module Division
| Module | Responsibility | Core API |
|--------|----------------|----------|
| Module A | ... | /api/a/* |
| Module B | ... | /api/b/* |

## 3. Module Details
### 3.1 Module A
**Responsibility**: ...
**Provided Functions**:
- Feature 1
- Feature 2
**Dependent Modules**:
- Module B (for ...)
**Key Classes/Interfaces**:
- ClassA
- InterfaceB

## 4. Module Relationships
[Diagrams or tables]

## 5. Core Business Flow
[Description of how key processes span modules]

Summary

Focus: what the system does (functionality).

Audience: users, product managers, developers.

Core elements: modules, responsibilities, relationships.

Expression methods: layered, domain model, service‑oriented.

Typical diagrams: module diagram, package diagram, class diagram.