对DDD设计的理解 [英] DDD design understanding
问题描述
我已经开始学习DDD了，我有几个问题，以便我能更好地理解它.
I've been starting to learn about DDD and I have couple of questions so that I can improve my understanding of it.
所以典型的DDD架构看起来像这样
So a typical DDD architecture looks like this
域层=>此层应与技术无关，并应包含以下内容
Domain Layer => this layer should be technology agnostic and should contain the following
Domain.Entities(与持久层Entities不同，应仅包含验证规则?其他任何域业务都应放在此处?)
Domain.Entities (different from the persistence layer Entities, should contain only validation rules ? any other domain business should go here?)
Domain.ValueObjects(不需要在域中唯一的对象，应该只包含验证规则)
Domain.ValueObjects (objects that do not require to be unique in the domain, should contain only validation rules)
Domain.Services(此层应包含业务逻辑，尽管与Aggregate相关，但不适合Aggregate本身.需要多个Domain.Entities和/或Domain.ValueObjects协同工作的业务协调器)
Domain.Services (this layer should contain business logic that although related to an Aggregate, does not fit into the Aggregate itself. orchestrators for operations that require multi Domain.Entities and/or Domain.ValueObjects collaborating together)
Domain.Factories(对这一层还没有完全了解，我的意思是它的责任是创建聚合或什么?)是纯粹的Factory Design Pattern还是与之不同?
Domain.Factories ( this layer is somehow not fully understood, i mean it's responsibility is to create Aggregates or what ?) Is it purely the Factory Design Pattern or is different from it?
Domain.Repositories(这一层也是模棱两可的，除了我知道该层负责与外部服务进行通信的事实外，它应该处理哪种类型的业务逻辑?)
Domain.Repositories (this layer is also ambiguous, except for the fact that i know that this layer is responsible to communicate with external services, what type of business logic should it handle?)
反腐败层(该层应充当域层和应用程序层之间的网关，它应负责将响应和请求从一层转换到另一层)
Anti-corruption layer (this layer should act as a gateway between the Domain layer and the Application Layer, it should be responsible with Translation of responses and requests from one layer to the other)
应用层=>仅应用于以客户端易于理解的格式公开数据.过滤是在此层(Linq-To-SQL)/(Linq-To-Entity)
Application Layer => should only be used to expose data in a format easy to understand by the Client. Filtering is done in this layer (Linq-To-SQL) / (Linq-To-Entity)
客户端(最终层)=>应该没有任何逻辑，只能公开应用层服务提供的模型.
Client (final layer) => should be free of any logic only exposes the models that the Application Layer Services provides.
我看到的其他层
Shared.Kernel(在多个有界上下文中共享的Domain.ValueObjects/Domain.Entites(不是AggregateRoot))
Shared.Kernel (Domain.ValueObjects / Domain.Entites (not AggregateRoots) that are shared across multiple Bounded Contexts)
Infrastructure.Domain.Common(在整个Domain中共享，例如AggregateRoot，BaseEntity，BaseValueObject等)
Infrastructure.Domain.Common(shared across the entire Domain, ex AggregateRoot, BaseEntity, BaseValueObject etc)
Infrastructure.DataAccess.Provider(例如EntityFramework/nHibernate/MongoDriver，此层应与之通信?应用程序层?
Infrastructure.DataAccess.Provider(example EntityFramework / nHibernate/ MongoDriver , with whom this layer should communicate ? the Application Layer ?
推荐答案
The place to start with DDD is "the blue book": Domain Driven Design by Eric Evans
典型的DDD架构看起来像
a typical DDD architecture looks like
分层架构.埃文斯回顾了四个概念层
a layered architecture. Evans recaps four conceptual layers
- 用户界面
- 应用程序
- 域
- 基础设施
Evans在第4章(隔离域)中指出
In Chapter 4 (Isolating the Domain), Evans points out
专门解决领域问题的软件部分通常只占整个软件系统的一小部分，尽管其重要性与其规模不成比例.为了运用我们的最佳思想，我们需要能够查看模型的元素并将其视为系统....我们需要将域对象与系统的其他功能分离，以便避免混淆域与其他仅与软件技术有关的概念或完全不了解该领域的概念.
The part of the software that specifically solves problems from the domain usually constitutes only a small portion of the entire software system, although its importance is disproportionate to its size. To apply our best thinking, we need to be able to look at the elements of our model and see them as a system.... We need to decouple the domain objects from other functions of the system, so we can avoid confusing the domain concepts with other concepts related only to software technology or losing sight of the domain altogether....
在域层"中，Evans识别出两种不同的关注点.
Within the "domain layer", Evans recognizes two different sets of concerns.
域实体，价值对象和域服务在软件中为业务建模(第5章).换句话说，这些元素为您的领域专家可以识别的概念建模.
Domain entities, value objects, and domain services model the business in the software (Chapter 5). In other words, these elements the model the concepts that your domain experts would recognize.
存储库和工厂是生命周期中的关注点-并非专家认为会与业务严格相关，而是充当应用程序层和域层之间的边界.
Repositories and Factories are life cycle concerns - not strictly related to the business as the experts would recognize it, but instead acting as the boundary between the application layer and the domain layer.
在Evan的表述中，业务规则的验证通常存在于域实体(而非域服务)中.正如OO样式中常见的那样，域实体结合了状态(域值)和行为(更改规则)-对持久层实体的任何更改(您是对的，不是同一回事)都是由于域执行的代码而发生的实体.
In Evan's formulation, the validation of business rules typically lives in the domain entities (not domain services). As is common in OO styles, the domain entities combine state (domain values) and behavior (rules for change) -- any change to a persistence layer entity (you are right, not the same thing) happens because of code executed by a domain entity.
反腐败层了解更多与外部数据源(可能是旧系统)集成，那么它们就是与应用程序层集成.
Anti corruption layers more about integrating with an external data source (perhaps a legacy system) then they are about integrating with the application layer.
在现代应用程序和它所依赖的旧系统之间实现外观或适配器层.该层在现代应用程序和遗留系统之间转换请求.使用此模式可确保应用程序的设计不受旧系统依赖的限制.
Implement a façade or adapter layer between a modern application and a legacy system that it depends on. This layer translates requests between the modern application and the legacy system. Use this pattern to ensure that an application's design is not limited by dependencies on legacy systems.
您可能想查看 github 上可用的DDD示例应用程序.这是关于不同部分如何组合在一起的不错的草图.
You might want to review the DDD Sample application available on github. It's a decent sketch of how the different pieces might fit together.
注意:如今，分层体系结构已不为其他替代方案所取代，我们开始看到更多有关以功能核心(而非OO风格)实现域模型的工作.
Note: these days, the layered architecture has lost ground to some of the other alternatives, and we are beginning to see more work on implementing the domain model with a functional core (rather than the OO style).
这篇关于对DDD设计的理解的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
