bor*_*ris 2 .net c# domain-driven-design ddd-repositories ddd-service
我一直在开始学习DDD,我有几个问题,这样我就可以提高对它的理解.
所以典型的DDD架构看起来像这样
Domain Layer =>此层应该是技术不可知的,应该包含以下内容
Domain.Entities(不同于持久层实体,应该只包含验证规则？任何其他域业务应该在这里吗？)
Domain.ValueObjects(域中不需要唯一的对象,应仅包含验证规则)
Domain.Services(该层应包含业务逻辑,虽然与Aggregate相关,但不适合Aggregate本身.协调器用于需要多个Domain.Entities和/或Domain.ValueObjects协同工作的操作)
Domain.Factories(这个层在某种程度上是不完全理解的,我的意思是它的责任是创建聚合或什么？)它纯粹是工厂设计模式还是与它不同？
Domain.Repositories(这个层也是模棱两可的,除了我知道这个层负责与外部服务通信,它应该处理什么类型的业务逻辑？)
反腐败层(该层应该充当域层和应用层之间的网关,它应该负责将响应和请求从一层转换到另一层)
Application Layer =>仅应用于以客户易于理解的格式公开数据.过滤在此层(Linq-To-SQL)/(Linq-To-Entity)中完成
客户端(最终层)=>应该没有任何逻辑,只暴露应用层服务提供的模型.
我看到的其他图层
Shared.Kernel(跨多个有界上下文共享的Domain.ValueObjects/Domain.Entites(不是AggregateRoots))
Infrastructure.Domain.Common(在整个域中共享,从AggregateRoot,BaseEntity,BaseValueObject等)
Infrastructure.DataAccess.Provider(示例EntityFramework/nHibernate/MongoDriver,该层应该与谁通信？应用层？
老实说，域驱动设计的前提会根据应用程序要求，业务任务和决定应用程序的基础架构而有所不同。域驱动设计的最简单解释。
数据层：抽象的数据层，将关注点与图形用户界面分离。
领域层：您的业务规则和逻辑，公司要求的基本基础，使命。
服务层：不是必需的，但可以充当图形用户界面和数据层之间的中介。建模数据到业务实体之间的清晰简洁转换。
应用层：您的用户界面，以有意义的方式为用户提供核心业务功能。
重要的概念是，没有一层相互依赖。他们都是独立的，彼此之间互为补充。您已经涉足更具体的上下文概念，它们在每个应用程序中都不相关或不可行。
根据您的示例，您可能会向外抽象域，以至于该层可能是贫乏的，而没有足够的相关性或有用的信息。如果以微服务方法，循环方法（干净架构）或分层方法编写，则传统的分层应用程序可以是域驱动设计。因为每种方法或样式都使用域驱动设计的基本目的，所以捕获了业务目的和任务。
应用程序不是域驱动的设计，因为您有一个层。您的应用程序将遵循一系列原则以符合域驱动设计。这些原则是为了确保您的应用程序适应业务变化。拥有代表业务的核心逻辑，同时随着业务目标在公司整个生命周期中的变化而不断变化。它们通常落在松耦合的一侧。
您提到的上述层中的一半是解决问题的复杂性模式。所有工具都有目的，例如模式，问题x使用螺丝刀，工厂可以解决x，但是存储库可以解决y。并非每种模式都适合每种用途。他们不是解决问题的小刀匠。
关于该主题有很多材料。福勒，埃文斯，沃恩和其他无数人。
| 归档时间： |
|
| 查看次数： |
2579 次 |
| 最近记录： |