【问题标题】:DDD on an enterprise scale?企业规模的 DDD?
【发布时间】:2011-08-16 11:28:34
【问题描述】:

寻找有关如何解决此问题的建议,并了解领域驱动设计是否真的是这里的最佳模式。

我的客户正在重新构建其几近过时的工具和服务堆栈。客户是一个快速扩张的电子商户。它的核心产品是它的大型电子商务网站。围绕该网站,客户拥有向其合作伙伴公开的各种数据源。大量内部应用程序可帮助营销、销售、报告等。大量用户支持和合作伙伴支持应用程序。大量的各种数据同步、ETL 作业等......你明白了。

数据存储和数据提供者也很丰富。 NOSQL 基于云的大型可扩展存储提供了公共网站上的大部分内容。具有多个数据库的 SQL 服务器为内部应用程序提供数据。还有一些特殊的仅搜索服务器可提供可扩展的搜索功能,以及应用程序从各种 3rd 方供应商处使用的其他提要。如果采用 DDD,计划是让各种存储库对象组继承自特定于数据存储的存储库基类

客户进行了一项练习,他们在“通用”级别上绘制了大部分业务实体:实体名称和关系。在这个“通用”级别之外,有大量不同具体对象在应用程序中的重用,以及大量实体的实现会有所不同,具体取决于应用程序。

例如:电子商务网站上的订单实体可能看起来像 X,而处理支持呼叫的应用可能看起来像 Y,此外还有像 Z 一样进行欺诈分析的人。

我正在寻找有关如何调整 DDD 或其他架构模式来处理这个巨大混乱的建议:制定一个可靠的企业战略,以促进重用并在必要时允许逻辑分离。在通常(可扩展、灵活、适应性强、可单元测试、简单等)标准之上。

由于不同的数据存储,DTO 的结构看起来与数据存储有很大不同。由于各种业务需求,各种应用程序需要某些实体的不同版本,而且由于公司正在迅速扩张,未来高度不稳定,灵活性至关重要。

我想我最大的问题是找到一种方法,将业务模型分离到不同的领域,并在大量共享或重用时将其保持在一起,同时能够适应高水平的变化。

感谢您的所有建议

附:该商店是微软商店。 VS2010/.NET/SQL/Azure

【问题讨论】:

    标签: .net entity-framework architecture domain-driven-design repository


    【解决方案1】:

    考虑 SOA + DDD

    从表面上看,您应该同时考虑面向服务的架构 (SOA) 和领域驱动设计 (DDD)。类似于 NServiceBus 的东西。

    Udi Dahan 在此处提供了有关 DDD + NServiceBus 的精彩视频:

    DDD 是关于隔离您的业务逻辑*

    DDD 的核心是将您的领域逻辑与您的应用程序和框架隔离开来,这样您就可以确保正确地对业务逻辑进行建模。 DDD 并不适用于每个项目,它绝对不适合维护 DDD 的成本高于您从中获得的收益的小型企业应用程序。

    你的情况

    您描述了一个相当复杂的业务规则集,IMO 将从 DDD 中受益匪浅。不过,我也会让您考虑一种 SOA,它可以让您使用通用消息传递系统将多个架构集成到一个企业级框架中。

    使用 SOA

    NServiceBus 是一个功能强大但轻量级的开源消息传递 用于设计分布式 .NET 企业系统的框架。完全 可插拔且易于使用,NServiceBus 为程序员提供了一个 在开发健壮、可扩展和可维护方面领先一步 服务层和长期运行的业务流程。

    【讨论】:

    • +1 “DDD 是关于隔离您的业务逻辑”。 @Igorek,您所看到的范围远不止于此。 (但我猜你已经这么想了)
    • @Igorek RE:“我想我最大的问题......”无论如何都要尝试“模型”(理解)更大的图景,但我会非常犹豫是否要真正实现一个“模型” “ 执行。尽量保持简单,不要忘记良好的旧 OO 原则(如关注点分离),因为它们仍然适用于宏观层面。
    猜你喜欢
    • 1970-01-01
    • 2015-07-09
    • 2013-04-02
    • 1970-01-01
    • 1970-01-01
    • 2020-01-21
    • 2013-08-13
    • 1970-01-01
    • 2011-02-04
    相关资源
    最近更新 更多