寻找如何解决这个问题的建议,并了解域驱动设计是否真的是最好的模式。企业规模的DDD?
我的客户是在重新架构的工具和服务,其近过时栈的过程。客户是一个迅速扩大的电子商家。它的核心产品是其大型电子商务网站。在这个网站的周围,客户有各种各样的数据馈送给它的合作伙伴。大量的内部应用程序可以帮助营销,销售,报告等等一系列用户支持和合作伙伴支持应用程序。大量的各种数据同步,ETL作业等......您可以获得图片。
数据存储和数据提供者也很多。 NOSQL基于云的大型可扩展存储提供了公共网站上的大部分内容。具有多个数据库的SQL服务器向内部应用程序提供数据。还有特殊的只搜索服务器可提供可扩展搜索功能,以及应用程序从各种第三方供应商处获取的其他供稿。如果采用DDD,则计划将具有从数据存储特定的存储库基类继承的各种存储库对象组
客户已经进行了一项练习,他们已经将他们的大部分业务实体映射到“通用”级别:实体名称和关系。除了“通用”级别之外,各种应用程序中各种具体对象的重用量还有相当大的数量,并且还有相当数量的实体会根据应用程序的不同实施。
例如:电子商务网站上订购实体可能看起来像X,而对于处理支持电话像Y,进而有人做欺诈分析像Z.
我在寻找的建议的应用如何适应DDD或其他架构模式来处理这个巨大的混乱:有一个坚实的企业战略,促进重用,并允许在必要时分离逻辑。在通常的(可扩展的,灵活的,适应性强,单元测试,简单等)标准之上。
由于不同的数据存储,DTO的结构看起来与数据存储到数据存储显著不同。由于各种业务需求,各种应用程序需要不同版本的特定实体,并且由于公司正在迅速扩张,未来非常不稳定,灵活性至关重要。
我想我最大的问题是找到一种方法来分离的经营模式不同域,仍然保持它在一起时,有共享或重用高量,同时能够采用高层次的变化。
谢谢您的所有建议
P.S.这家商店是一家微软商店。 VS2010/.NET/SQL/Azure的
+1“DDD是关于隔离您的业务逻辑”。 @Igorek,你看到的规模超出了这个范围。 (但我想你已经在想) –
@Igorek RE:“我想我最大的问题......”通过一切手段尝试和“模型”(理解)更大的图片,但我会非常犹豫要实际实施单一“模式”实施。尽量保持简单,不要忘记旧的OO原则(如关注点分离),因为它们仍然适用于宏观层面。 –