Enterprise Development Frameworks: Vertical and Horizontal Architecture, SOA, and Microservices

Enterprise development frameworks include vertical and horizontal architectures. Vertical architecture refers to a multi‑layered, stacked design for a single application (monolithic program). Horizontal architecture splits a large application into several smaller services (distributed system). Both Java and .NET ecosystems offer strong framework support; ASP.NET Core is lightweight, high‑performance, and suitable for both monolithic and distributed systems. With the rise of microservices, mixed‑language applications are becoming common.

1. Vertical Architecture

1.1 Multi‑layer Architecture

The layered architecture builds loosely coupled applications through package or component isolation. The onion model is illustrated below:

1.1.1 Domain Model

Includes domain entities, repository interfaces, and service interfaces – the core of the program.

Anemic Model

If most business logic is delegated to service implementations, the domain model becomes thin (anemic), representing only state. Advantages: easy to understand and implement. Disadvantages: as business grows, the model may struggle to express domain concepts.

Rich (Charged) Model

When the domain model implements the main business logic, it becomes richer. Objects contain both state and behavior, grouped under an aggregate root that ensures consistency. Advantages: easier to evolve with business; disadvantages: harder to master.

1.1.2 Repository

After creation, domain objects are persisted to a database and later reconstructed. The repository provides collection‑like interfaces for creating, reading, updating, and deleting entities.

Anemic Model repository implements CRUD for entities.

Rich Model repository creates aggregate roots; creation, update, and deletion are performed by the root.

1.1.3 Services

Three typical service types: Application Service, Domain Service, and Infrastructure Service.

Application Service: orchestrates domain services, provides transaction context, can expose APIs directly.

Domain Service: offers business functionality within a specific context (e.g., order creation, order tracking).

Infrastructure Service: provides technical utilities such as logging, security, communication, event bus, etc.

1.1.4 UI

Provides the user interface, often built on UI frameworks like MVC. Examples include MFC, WinForm, ASP.NET WebForm, ASP.NET MVC, and others.

Summary : The onion model enforces a single‑direction dependency from outer to inner layers, reducing coupling.

2. Typical Frameworks

2.1 Data Access Frameworks

2.1.1 Data Access Helpers

These frameworks expose a uniform API for connection, command, and result‑set handling across different databases.

Advantages:

High performance with raw SQL.

Explicit transaction control.

Support for multiple storage types.

Lightweight with few dependencies.

Disadvantages:

SQL errors are easy to introduce; require thorough unit testing.

SQL refactoring becomes harder as the database evolves.

Framework

Features

Language

JDBC

Simple, fast to learn, highly flexible SQL construction, high efficiency

Java

ADO.NET

Clear interfaces, supports offline DataSet traversal, works with database and non‑database sources

C#

2.1.2 Object‑Relational Mapping (ORM)

ORM maps objects to relational tables, enabling CRUD operations via objects.

Advantages:

Improves development efficiency and reduces cost.

Promotes object‑oriented development.

Portable across databases.

Easy to add features like caching.

Disadvantages:

Performance overhead (generally acceptable).

Complex queries can become cumbersome.

Framework

Features

Language

Dapper

Semi‑automatic, lightweight, strong SQL control, small footprint

C#

Entity Framework

Fully automatic, heavyweight, supports LINQ and raw SQL, powerful

C#

Hibernate

Powerful, database‑agnostic, strong O/R mapping, requires HQL learning

Java

iBATIS (MyBatis)

Easy to start, simple, requires writing SQL

Java / .NET

2.2 MVC Frameworks

Model: provides data binding and business logic.

View: renders the user interface (desktop windows, web pages, etc.).

Controller: receives user events, dispatches them to interested models, and coordinates updates.

2.2.1 Classic MVC

Common in complex desktop applications (e.g., MFC) and rich web frameworks (e.g., AngularJS 1).

2.2.2 Backend MVC

In web applications, the controller receives HTTP requests, invokes the model, receives a view object (VO), and returns HTML/JSON/file streams. Backend MVC controllers should stay thin; complex UI logic can be handled by frontend MVC frameworks.

2.2.3 Typical MVC Frameworks

Framework

Features

Language

Front/Back

Asp.net MVC

Supports WebForm and Razor

C#

Back

Nancy

Lightweight, flexible routing

C#

Back

Struts2

Pioneer of Java MVC, heavyweight, limited abstraction

Java

Back

Spring MVC

Higher development efficiency and performance than Struts2, zero‑configuration

Java

Back

AngularJS

Full‑featured, two‑way binding, decent performance, v2 improves on v1

JavaScript

Front

React

Virtual DOM, high performance, UI‑component focused

JavaScript

Front

Vue

Small core, view‑layer focused, requires additional libraries for full MVC

JavaScript

Front

2.3 IoC Frameworks

2.3.1 Concepts

IoC (Inversion of Control) and DI (Dependency Injection) invert the traditional control flow: instead of the application creating objects, the framework creates and manages them, enabling loose coupling and easier testing.

2.3.2 Typical DI Frameworks

Framework

Features

Language

Unity

Part of Microsoft Enterprise Library, stable performance

C#

Autofac

Lightweight, high performance

C#

Spring

Heavyweight, feature‑rich

Java

2. Horizontal Architecture

Multi‑layer architecture suits monolithic programs, but as a project grows, extending a single codebase becomes difficult and performance bottlenecks appear. Splitting functionality into independent services (horizontal architecture) reduces coupling, improves deployment flexibility, and allows targeted performance tuning.

1. SOA Architecture

Service‑Oriented Architecture (SOA) builds distributed applications by exposing functionality as services.

1.1 Simplified SOA Diagram

1.2 Basic Service Elements

Policy – rules that a consumer must satisfy (e.g., security token).

Endpoint – network address (protocol, host, port).

Contract – agreement on input/output data (XML, JSON, etc.).

Message – payload that conforms to the contract.

1.3 Service Governance

Key governance topics include service definition, lifecycle, versioning, migration, registry, message model, monitoring, ownership, testing, and security. Adding an ESB (Enterprise Service Bus) is a common solution.

2. Microservice Architecture

Microservices are an evolution of SOA that further decompose services.

2.1 Simplified Microservice Diagram

2.2 Service Elements

Microservices expose REST endpoints; policies and contracts are often implicit.

2.3 Service Governance

Microservice governance mirrors SOA but at larger scale. While some argue microservices should avoid a central ESB, API gateways often provide similar functions such as security, transaction management, and workflow orchestration.

3. Monolithic vs SOA vs Microservices

Architecture

Initial Development Efficiency

Iterative Development Efficiency

Extensibility

Maintainability

Monolithic

High

Medium, tends to decline

Low

High

SOA

Medium

Medium, stable

Medium

Medium

Microservices

Low

High, stable

High

Low

Recommendation: small teams or simple projects benefit from monolithic development; legacy‑heavy systems may adopt SOA; brand‑new, rapidly evolving large projects should consider microservices.

4. Typical SOA Frameworks

Framework

Features

Open Source?

WCF

Microsoft product, Windows‑only, supports HTTP, TCP, named pipes, and extensible message formats

Client side open source

Spring Integration

Lightweight Spring‑based integration framework, ESB alternative

Yes

Mule ESB

Full‑featured ESB with visual Studio, DSL‑like configuration

Yes

Apache Camel

Extensive component library, comparable to Mule ESB

Yes

5. Typical Microservice Frameworks

Framework

Language

Developer

Maintenance Status

Typical Use Cases

Protocol

Supported Languages

Distributed Transactions

Stateless Deployment

Server‑Side Governance

Dubbo

Java

Alibaba

No longer maintained

Alibaba, JD, Dangdang, etc.

Optional (default Dubbo)

Java

No

Yes

Service discovery, routing, load balancing, clustering, dependency management, weighting, authorization, direct calls, context propagation, result caching

Spring Cloud

Java

Spring Community

Active

China Telecom, Huawei, Neusoft, etc.

HTTP

All languages

No

Yes

Gateway, circuit breaker, tracing, message bus, batch tasks

Surging

C#

Individual

Average

None listed

IPC

C#

No

Yes

High‑performance RPC, Zookeeper/Consul registration, hash/round‑robin load balancing, Netty async transport

3. Conclusion

For monolithic applications, the onion model works well. Use data‑access frameworks for persistence and MVC frameworks for UI. Legacy‑heavy systems can be integrated via SOA, while large, evolving systems benefit from microservices. New large‑scale projects are often best started with microservices.

References:

http://blog.csdn.net/sinat_34093604/article/details/53082000

http://www.jdon.com/soa/integration-framework-comparison-spring.html

http://blog.csdn.net/qiumuxia0921/article/details/52713791

http://openwares.net/java/dip_ioc_di.html

http://www.cnblogs.com/summer7310/p/6394379.html

http://www.cnblogs.com/wangpenghui522/p/5430292.html

http://blog.csdn.net/zhengzhb/article/details/7190158

http://www.cnblogs.com/fanliang11/p/7191030.html

http://blog.csdn.net/orichisonic/article/details/48546061

Source: http://www.cnblogs.com/vipyoumay/p/7735750.html

Copyright notice: The article is jointly owned by the author and the blog platform. Re‑publishing is allowed with this notice retained and a visible link to the original article.