Question

我正在设计一个更大的企业架构，我对如何分离模型和设计这些模型存在疑问。有几点我想建议： - 要定义的模型 - 定义模型的方法

目前我的想法是定义：

核心（域）模型
存储库到从a获取数据到该域模型数据库或其他商店
包含的业务逻辑模型业务逻辑，验证逻辑和更具体的形式版本数据检索方法
查看为特定格式准备的模型将被解析的数据输出不同种类的观点（网络，银光等）。

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

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

我应该将Domain模型和BusinessLogic模型分开还是整合它们？

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

这是我想到的一个例子： architecture figure 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

我不认为在企业的每个应用程序中强制执行此类设计都是一个好主意。这是非常具体的。您如何预测个别应用程序的需求？

其次，您提出的内容实际上不是域驱动的设计。它看起来像微软祝福的n层方法。你所拥有的是所有3层的数据结构。为什么要将“域模型”与业务模型分开？对于大多数复杂系统而言，包含数据和行为的丰富域模型应该足够了。 View模型可以建立在这个模型之上（简单，经典的解决方案）或直接来自数据库（CQRSish解决方案）。后者似乎在复杂的情况下效果更好。

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

我的建议是，如果你想要域名模型，坚持使用DDD建模实践（Eric Evans，Jimmy Nilsson）并且不遵循App Archi Guide的字面意思。如有必要，请在解决方案中添加一点CQRS，以便从UI相关问题中清除模型。这样就可以避免与集合处理相关的各种问题。

有关多个模型和聚合的.NET系统体系结构设计的良好实践

1 个答案: