Port/Adapter（洋葱）架构技术问询：无持久化时是否需领域层及微服务分层合理性

Let’s tackle your two questions one by one—they’re really insightful for getting to the heart of why onion architecture works, beyond just the basic setup.

1. Do I still need a domain layer if my application has no persistence mechanism? #

Absolutely—the domain layer’s purpose isn’t tied to persistence at all. The core of the domain layer is encapsulating your business rules, domain entities, and business logic that makes your application unique. Even if you never save data to a database or any storage, if your app has business logic that needs to be reused, validated, or kept isolated from external concerns, you need a domain layer.

For example, imagine a service that calculates shipping costs based on weight, destination, and customer tier. You don’t need to persist anything here, but you have complex rules: "Premium customers get 15% off for international shipments over 5kg", "Domestic shipments under 2kg are free". If you dump these rules directly in the application or web layer, they’ll be scattered, hard to test, and impossible to reuse if you add another entry point (like a CLI or mobile API later).

The only scenario where you might skip a domain layer is if your app is purely a pass-through—no logic at all, just forwarding requests from one system to another. But even then, if you ever add any validation or business logic later, you’ll wish you had the domain layer in place from the start.

2. Is having a domain layer and associated conversion operations reasonable in my current setup? #

100% reasonable—even if your app primarily moves data between the web and infrastructure layers, the domain layer and conversion steps are what keep your system maintainable and adaptable. Let’s break this down:

• Domain layer as the core: Right now, you might think the data is just flowing through, but there’s almost certainly business logic hidden in that flow. For example, before sending an order to the inventory system, do you need to validate that the order items are in stock? That the customer’s order doesn’t exceed their allowed limit? That the order details follow your business’s specific formatting rules? All of this belongs in the domain layer—either in domain entities (like Order with validation logic) or domain services.

• Conversion operations (DTO ↔ domain objects): These are critical for separating concerns. Your web layer’s DTOs are designed for frontend needs—maybe they include display-only fields, or exclude sensitive data. Your infrastructure layer uses models tailored to the inventory system’s API (maybe different field names, data formats). The domain layer’s objects are pure business-focused, with no ties to external systems or frontend requirements.

By converting between these layers, you insulate your core business logic from changes in external systems. If the inventory system updates its API schema, you only need to adjust the conversion in the infrastructure layer—not touch the domain logic. If the frontend needs a new field in the DTO, you adjust the web layer conversion without impacting how your business validates or processes orders.

Think of it this way: the domain layer is the "brain" of your app, and the conversion steps are the translators that let the brain talk to the outside world without having to learn every external system’s language.

内容的提问来源于stack exchange，提问作者E. Roid