Understanding the Development View: A Floor‑Plan for Code Organization
The article explains the Development View— the "code floor plan" in the 4+1 view model—by detailing how code is organized, directory structures, module dependencies, build and packaging configurations, common architectural patterns, design principles, and practical solutions to typical problems such as circular dependencies and package chaos.
1. What Is the Development View?
The Development View is the "code floor plan" component of the 4+1 view model. While the Logical View tells you "what rooms exist," the Development View shows "how each room is furnished" for developers.
Core Concerns
How the code is organized
What the directory structure looks like
Dependencies between modules
Build and packaging approaches
Simple interpretation: the Development View is a floor‑plan that developers can read.
2. Core Focus of the Development View
2.1 Code Organization – Layered Structure
project
├── src/main/java/ // Java source code
│ ├── com.company // Company package
│ │ ├── controller/ // Controller layer
│ │ ├── service/ // Service layer
│ │ ├── repository/ // Data‑access layer
│ │ ├── model/ // Model layer
│ │ └── config/ // Configuration classes
│ └── resources/ // Resource files
├── src/test/ // Test code
├── pom.xml // Maven configuration
└── README.md // Project description2.2 Dependency Management
Internal dependencies (project modules)
user-service ──→ common-lib
│
└──→ domain-modelExternal dependencies (third‑party libraries)
Spring Boot
│
├── Spring Web
├── Spring Data JPA
└── Spring Security2.3 Build Configuration
Compilation configuration
Test configuration
Packaging configuration
Deployment configuration
3. Representations of the Development View
3.1 Package Diagram
Structure diagram
┌─────────────────────────────────────────┐
│ User Service Package │
├─────────────────────────────────────────┤
│ │
│ ┌─────────────┐ ┌─────────────┐ │
│ │ controller │ │ service │ │
│ │ │ │ │ │
│ │UserController││UserService │ │
│ └─────────────┘ └─────────────┘ │
│ │ │ │
│ └───────┬────┘ │
│ │ │
│ ┌──────▼───────┐ │
│ │ repository │ │
│ │ │ │
│ │UserRepository│ │
│ └──────────────┘ │
└─────────────────────────────────────────┘3.2 Module Dependency Diagram
┌─────────────────────────────────────────────────────┐
│ Project Dependency Structure │
├─────────────────────────────────────────────────────┤
│ │
│ ┌─────────────┐ │
│ │ api-war │ ← Web layer │
│ │ (External API) │ │
│ └──────┬──────┘ │
│ │ │
│ ┌─────────────────┼─────────────────┐ │
│ │ │ │ │
│ ┌─▼─┐ ┌────▼────┐ ┌────▼────┐ │
│ │user-service│ │order-service│ │product-svc│ │
│ └─┬─┘ └────┬────┘ └────┬────┘ │
│ │ │ │ │
│ └─────────────────┼─────────────────┘ │
│ │ │
│ ┌──────▼──────┐ │
│ │ common-lib │ ← Shared library │
│ └──────┬──────┘ │
│ │ │
│ ┌─────────────────┼─────────────────┐ │
│ │ │ │ │
│ ┌─▼─┐ ┌────▼────┐ ┌────▼────┐ │
│ │mybatis│ │ redis │ │ kafka │ │
│ │extension│ │ client │ │ client │ │
│ └───────┘ └─────────┘ └─────────┘ │
└─────────────────────────────────────────────────────┘3.3 Directory Tree
project-root/
│
├── docs/ // Documentation
│ ├── api/
│ └── design/
│
├── config/ // Configuration
│ ├── dev/
│ ├── test/
│ └── prod/
│
├── modules/ // Business modules
│ ├── module-user/ // User module
│ │ ├── src/
│ │ ├── pom.xml
│ │ └── README.md
│ ├── module-order/ // Order module
│ │ ├── src/
│ │ ├── pom.xml
│ │ └── README.md
│ └── module-product/ // Product module
│ ├── src/
│ ├── pom.xml
│ └── README.md
│
├── libraries/ // Shared libraries
│ ├── common-utils/
│ └── common-data/
│
├── build/ // Build scripts
│ ├── build.sh
│ └── docker/
│
├── pom.xml // Parent POM
└── README.md4. Common Code‑Organization Patterns
4.1 Layered Organization
com.company.app
├── controller/ // Handles requests
├── service/ // Business logic
├── repository/ // Data access
├── model/ // Data models
│ ├── entity/ // Entity classes
│ ├── dto/ // Data‑transfer objects
│ └── vo/ // View objects
└── config/ // Configuration classesApplicable scenario: traditional web applications.
4.2 Feature‑Based Organization
com.company.app
├── user/ // User feature
│ ├── UserController
│ ├── UserService
│ ├── UserRepository
│ └── User
├── order/ // Order feature
│ ├── OrderController
│ ├── OrderService
│ ├── OrderRepository
│ └── Order
└── product/ // Product feature
├── ProductController
├── ProductService
├── ProductRepository
└── ProductApplicable scenario: micro‑services with clear business boundaries.
4.3 Onion Architecture
├── domain/ // Core domain layer
│ ├── model/
│ ├── repository/
│ └── service/
│
├── application/ // Application layer
│ ├── usecase/
│ └── dto/
│
├── infrastructure/ // Infrastructure layer
│ ├── persistence/
│ ├── messaging/
│ └── external/
│
└── presentation/ // Presentation layer
├── web/
└── api/Applicable scenario: DDD projects, complex business logic.
4.4 Hexagonal Architecture
├── core/ // Core business
│ ├── model/
│ ├── port/ // Ports (interfaces)
│ │ ├── inbound/ // Inbound ports
│ │ └── outbound/ // Outbound ports
│ └── service/
│
├── adapter/ // Adapters
│ ├── primary/ // Driving adapters
│ │ └── web/
│ └── secondary/ // Driven adapters
│ ├── persistence/
│ └── external/
│
└── application/ // Application orchestrationApplicable scenario: architectures that require high decoupling.
5. Design Principles for the Development View
5.1 Dependency Principles
Stable Dependency Principle
Stable module
↑
Unstable module
Stable modules should not depend on unstable modules.Stable Abstraction Principle
Abstract Interface
↑
┌─────────┴─────────┐
│ │
Implementation A Implementation B
Higher abstraction → higher stability.Dependency Inversion Principle (DIP)
High‑level module ──→ Abstract Interface
↑
Low‑level module ──→ Implementation
High‑level modules depend on abstractions, not on low‑level details.5.2 Module‑Division Principles
Single Responsibility: each module does one thing.
Clear Boundaries: cross‑module calls go through interfaces.
Minimal Dependencies: keep inter‑module dependencies low.
Consistency: naming and structure should be uniform.
5.3 Package‑Structure Design
Recommendation: combine top‑down layering with bottom‑up dependencies.
┌─────────────┐
│ Web Layer │ ← Top layer
└──────┬──────┘
│ depends on
┌──────▼──────┐
│ Service Layer│
└──────┬──────┘
│ depends on
┌──────▼──────┐
│ Repository │
└──────┬──────┘
│ depends on
┌──────▼──────┐
│ Model │ ← Bottom layer
└─────────────┘6. Common Issues and Solutions
6.1 Circular Dependencies
Problem code:
Module A → Module B → Module ASolutions:
Extract a shared module.
Refactor module responsibilities.
Apply Dependency Inversion.
6.2 Dependency Explosion
Problem: a module depends on 100 JARs.
Solutions:
Import only what is needed.
Split the dependency into smaller modules.
Use optional dependencies.
6.3 Chaotic Package Structure
Problem: a util package contains 50 unrelated classes.
Solutions:
Split utilities by feature.
Move utilities to the appropriate module.
Clean up dead code.
7. Summary
The Development View helps developers understand code organization, dependencies, and build configuration. Key takeaways:
The view is for developers and must match development habits.
A clear directory structure lets anyone locate code instantly.
Explicit dependency relationships avoid circular references.
Consistent naming and conventions maintain overall coherence.
Target audience: developers and build engineers.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
IT Learning Made Simple
Learn IT: using simple language and everyday examples to study.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.