领域模型类是否仅依赖Python原生类型？多源实例化方案咨询

Great questions—let's break these down clearly, since you're working through Architecture Patterns with Python which focuses on keeping domain logic clean and decoupled.

Question 1: Must domain model classes only depend on Python native types? Are there exceptions? #

The short answer: It's not an absolute rule, but it's a strong best practice recommended by the book (and DDD principles more broadly). Here's why:

• Domain models exist to encapsulate your core business logic, not technical implementation details. By using native types (lists, dicts, floats, etc.), you keep the domain layer independent of external libraries like NumPy, Pandas, or database ORMs. This makes it easier to test your business logic in isolation, swap out external tools later (e.g., switch from NumPy to PyTorch), and keep your domain rules from getting tangled with technical code.
• Exceptions do exist: If an external type is a fundamental part of your domain concept and is extremely stable (unlikely to change), you might consider allowing it. For example, if your entire domain revolves around numerical matrix operations and NumPy arrays are the de facto standard for representing depth maps in your industry, you could argue it's part of the domain abstraction. But even then, many developers would still wrap it in a domain class to add validation or business rules, rather than directly exposing the NumPy array.

In your original example, using a NumPy array directly in __init__ ties your domain model to NumPy. If you later need to support a different array library, you'd have to modify the DepthMap class itself—which violates the open/closed principle (open for extension, closed for modification).

Question 2: What's the right way to create domain model objects from different data sources? #

Let's evaluate your options, and clear up a common misconception about the Repository Pattern:

Option 1: Class Methods (e.g., from_numpy, from_str) #

This is my go-to for simple conversion logic. It keeps the creation logic closely tied to the domain class, making it intuitive to use (e.g., DepthMap.from_numpy(my_np_array)).

Pros:

• Simple to implement and read.
• Doesn't require extra classes cluttering your codebase.

Cons:

• If you have many complex creation workflows (e.g., validations, multi-step transformations), your domain class can get bloated with non-business logic.

Option 2: Factory Class #

Use this when your creation logic gets complex, or you want to separate domain logic from instantiation logic entirely. A factory class centralizes all the ways to create a DepthMap, keeping your domain class focused only on business rules.

Pros:

• Keeps the domain class clean (single responsibility principle: DepthMap handles business logic, factory handles creation).
• Easier to extend if you add more data formats later (just add a new static method to the factory).

Cons:

• Adds an extra class, which is overkill for simple conversions.

Option 3: Repository Pattern (Your Proposed Usage) #

Wait a minute—this is a misapplication of the Repository Pattern! Repositories are meant to abstract data persistence (e.g., loading a DepthMap from a database, saving it to a file, or fetching it from an API). They're not for converting in-memory data types (like NumPy arrays or strings) to domain objects. Using repositories here would blur the line between data access logic and type conversion, which is confusing for other developers reading your code.

Recommendation #

• Start with class methods for simple conversions (like your NumPy to list example). They're straightforward and fit well with the domain class.
• If your creation logic grows more complex (e.g., adding detailed validation, handling edge cases, or integrating with external services), refactor to a factory class to keep your domain model focused.
• Always add validation logic during creation (either in __init__ or the factory/class method) to ensure your DepthMap objects are valid according to your domain rules. For example, checking that depth values are within a valid range, or that the map is a 2D structure.

Here's an improved example with validation added to class methods:

from typing import List
import numpy as np

class DepthMap:
    def __init__(self, map: List[List[float]]):
        # Enforce domain rules in __init__ to ensure valid objects
        self._validate_map(map)
        self.map = map

    def _validate_map(self, map: List[List[float]]):
        if not isinstance(map, list) or not all(isinstance(row, list) for row in map):
            raise ValueError("Depth map must be a 2D list")
        for row in map:
            for val in row:
                if not 0.0 <= val <= 1.0:
                    raise ValueError(f"Depth value {val} must be between 0 and 1")

    @classmethod
    def from_numpy(cls, map: np.ndarray):
        if map.ndim != 2:
            raise ValueError("NumPy array must be 2D for a depth map")
        if (map < 0).any() or (map > 1).any():
            raise ValueError("All depth values must be between 0 and 1")
        return cls(map.tolist())

    @classmethod
    def from_str(cls, map_str: str):
        try:
            rows = map_str.split(";")
            map_data = [[float(val.strip()) for val in row.split(",")] for row in rows]
        except ValueError as e:
            raise ValueError(f"Invalid string format: {str(e)}")
        return cls(map_data)

This way, every DepthMap instance you create is guaranteed to follow your domain rules, regardless of the input format.

内容的提问来源于stack exchange，提问作者Ramon