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
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