企业规模的 DDD？
寻找有关如何解决此问题的建议，并了解领域驱动设计是否真的是最好的模式。
我的客户正在重新构建其近乎过时的工具和服务堆栈。客户是一家快速扩张的电子商务商。其核心产品是大型电子商务网站。在该网站上，客户拥有向其合作伙伴公开的各种数据源。大量内部应用程序可帮助营销、销售、报告等。大量用户支持和合作伙伴支持应用程序。大量的各种数据同步、ETL 作业等......您明白了。
数据存储和数据提供者也很丰富。基于 NOSQL 云的超可扩展存储提供了公共网站上的大部分内容。具有多个数据库的 SQL 服务器为内部应用程序提供数据。还有特殊的仅搜索服务器，可提供可大规模扩展的搜索功能，以及应用程序使用的来自各个第三方供应商的其他源。如果采用 DDD，计划将是让各种存储库对象组从特定于数据存储的存储库基类继承。
客户已进行了一项练习，他们已在“通用”级别上映射了大部分业务实体：实体名称和关系。在“通用”级别之外，跨应用程序有相当多的各种具体对象的重用，并且有相当多的实体在实现上有所不同，具体取决于应用程序。
例如：电子商务网站上的订单实体可能看起来像 X，而处理支持呼叫的应用程序可能看起来像 Y，此外对于进行欺诈分析的人来说可能看起来像 Z。
我正在寻找有关如何适应 DDD 或其他架构模式的建议处理这个巨大的混乱：制定可靠的企业战略，促进重用并在必要时允许逻辑分离。在通常的（可扩展、灵活、适应性强、可单元测试、简单等）标准之上。
由于数据存储不同，不同数据存储的 DTO 结构看起来有很大不同。由于不同的业务需求，各种应用程序需要某些实体的不同版本，并且由于公司正在快速扩张，因此未来高度不稳定，灵活性至关重要。
我想我最大的问题是找到一种方法将业务模型分离到不同的领域，并在存在大量共享或重用时仍然将其保持在一起，同时能够适应高水平的变化。
感谢您的所有
建议该商店是微软商店。 VS2010/.NET/SQL/Azure
Looking for suggestions on how to approach this problem and to understand if Domain Driven Design is really the best pattern here.
My client is in the process of re-architecting its near-obsolete stack of tools and services. Client is a rapidly expanding e-merchant. It's core product is its large e-commerce website. Around this website, the client has a variety of data feeds that it exposes to its partners. A slew of internal applications to help in marketing, sales, reporting, etc. A slew of user support and partner support applications. A good amount of various data-syncs, ETL jobs, etc... You get the picture.
Data stores and data providers are also plentiful. NOSQL cloud-based mega-scalable storage provides most of the stuff on the public website. SQL-servers with a number of databases provide data to internal applications. There are also special search-only servers to provide megascalable searching capabilities, as well as other feeds that apps consume from various 3rd party vendors. If DDD is adopted, the plan would be to have various groups of repository objects inherit from data store-specific repository base classes
There has been an exercise performed by the client where they have mapped out most of their business entities on a "generic" level: entity names and relationships. Outside of that "generic" level, there is a decent amount of reuse of various concrete objects across applications as well as there is a decent amount of entities that would differ in their implementation, depending on an app.
For example: Order entity on an ecommerce website may look like X, while for an app that handles support calls like Y, and furthermore for someone doing fraud analysis like Z.
I'm looking for suggestions on how to adapt DDD or another architectural pattern to handle this giant mess: have a solid enterprise strategy that facilitates reuse and allows for separation of logic if necessary. On top of the usual (scalable, flexible, adaptable, unit-testable, simple, etc) criteria.
Due to different data stores, structure of DTO's looks significantly different from data-store to data-store. Due to various business needs, various apps need different versions of certain entities, and since the company is rapidly expanding, the future is highly unstable and flexibility is paramount.
I guess my biggest problem is finding a way to separate the business model to different domains and still keep it together when there is high amount of sharing or reuse, while being able to adopt to high level of change.
Thank you for all your suggestions
P.S. The shop is a Microsoft shop. VS2010/.NET/SQL/Azure
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
考虑 SOA + DDD
从表面上看，您似乎应该考虑面向服务的架构 (SOA) 以及领域驱动设计 (DDD)。类似于NServiceBus。
Udi Dahan 在此处提供了有关 DDD + NServiceBus 的精彩视频：
DDD 是关于隔离您的业务逻辑*
DDD 的核心是将您的领域逻辑与您的应用程序和框架隔离，以便您可以确保正确地对业务逻辑进行建模。 DDD 并不适合每个项目，它绝对不适合小型企业应用程序，因为维护 DDD 的成本高于您从中获得的收益。
在您的案例中
您描述了一个相当复杂的业务规则集，IMO 将从 DDD 中受益匪浅。不过，我也会让您考虑一种 SOA，它允许您使用通用消息传递系统将多个架构集成到一个企业级框架中。
使用 SOA
Consider SOA + DDD
On the surface it looks like you should be considering Service Oriented Architecture (SOA) along with Domain Driven Design (DDD). Something along the lines of NServiceBus.
Udi Dahan has a great video on DDD + NServiceBus available here:
DDD is about isolating your business logic*
DDD at its core is isolating your domain logic from your application and framework so that you can ensure that you are modelling the business logic correctly. DDD is not for every project, it's definetly not suitable for small business applications where the cost of Maintaining DDD is higher than the benefits you gain from it.
In your case
You've described a fairly complex business ruleset which IMO would benefit highly from DDD. I would however also get you to consider a SOA which can allow you to integrate multiple architectures into 1 enterprise level framework using a universal messaging system.
Using SOA