.NET 系统架构设计中涉及多个模型和聚合的良好实践是什么

Question

我正在设计一个更大的企业架构，我对如何分离模型并设计它们感到疑问。 有几点我希望得到建议： - 模型定义 - 定义模型的方式

目前我的想法是定义：

1. 核心（域）模型
2. 存储库 从 a 获取数据到该域模型 数据库或其他存储业务
3. 逻辑模型将包含 业务逻辑、验证逻辑和 形式的更具体版本 数据检索方法
4. 查看为专门格式化而准备的模型 将被解析的数据输出 不同类型的视图（网络、 银光等）。

对于第一个模型，我对使用什么以及如何定义模式感到困惑。 该模型实体是否应该包含集合以及以什么形式？ IList、IEnumerable 或 IQueryable 集合？ - 我正在考虑 IEnumerable 所属的不可变集合，但我想避免庞大的数据集合，并通过 LINQ 表达式为我的业务逻辑层提供访问权限，以便查询树在数据级别执行并仅检索情况下真正需要的数据就像我在数千或数十万个元素中检索非常特定的元素子集时一样。

如果我的商品有数千个出价怎么办？我不能只创建模型上的 IEnumerable 集合，然后在某些存储库方法甚至业务模型方法中检索项目列表。 它应该是 IQueryable 以便我实际上将查询从业务逻辑模型层一直传递到存储库吗？ 我应该避免在域模型中使用集合吗？我应该只作废一些收藏吗？

我应该将领域模型和业务逻辑模型分开还是将它们集成？

数据将通过使用域模型类的存储库进行处理。是否应该仅使用域模型中的类（例如数据容器）直接使用存储库？

这是我的想法的一个例子： 架构图1 http://img199.imageshack.us/img199/7364/arch1p.jpg

因此，我的 Domain 对象看起来像（例如），

public class Item
    {
        public string ItemName { get; set; }
        public int Price { get; set; }
        public bool Available { get; set; }
        private IList<Bid> _bids;
        public IQueryable<Bid> Bids
        {
            get { return _bids.AsQueryable(); }
            private set { _bids = value; }
        }
        public AddNewBid(Bid newBid)
        {
            _bids.Add(new Bid {....
        }
    }

其中 Bid 将被定义为普通类。

存储库将被定义为数据检索工厂，用于将数据获取到另一个（业务逻辑）模型，该模型将再次用于将数据获取到 ViewModel，然后由不同的消费者呈现。

我将为所有聚合集合定义 IQueryable 接口，以获得灵活性并最大限度地减少从实际数据存储中检索的数据。

或者我应该使用纯数据存储实体和为业务逻辑模型定义的所有集合来使域模型“贫血”？

最重要的问题之一是，哪里有 IQueryable 类型集合？ - 从存储库到业务模型的所有方式，或者根本不公开，仅公开存储库中的可靠 IList 和 IEnumerable，并处理业务模型内更具体的查询，但在存储库内具有更细粒度的数据检索方法。

那么，你觉得怎么样？有什么建议吗？

Answer 1

我认为首先在企业的每个应用程序中强制进行这样的设计并不是一个好主意。这是非常具体的。您如何预测各个应用程序的需求是什么？

其次，您所呈现的实际上不是领域驱动的设计。它看起来像是 Microsoft 祝福的 n 层方法。您拥有的是所有 3 层的数据结构。为什么要将“领域模型”与业务模型分开？包含数据和行为的丰富域模型对于大多数复杂系统来说应该足够了。视图模型可以构建在此模型之上（简单、经典的解决方案），也可以直接从数据库构建（CQRSish 解决方案）。后者似乎在复杂的场景中效果更好。

您询问的商品有数千个出价。好吧，也许 bid 是一个聚合根（您缺少的一个域概念），并且不应该包含在任何集合中。

我的建议是，如果您想要领域模型，请坚持 DDD 建模实践（Eric Evans、Jimmy Nilsson），不要严格遵循 App Archi Guide。如有必要，请在您的解决方案中添加一点 CQRS，以清除模型中与 UI 相关的问题。这样您就可以避免与集合处理相关的各种问题。