For data centric operations you would probably be better off using something like an Active
Record pattern,or even a DAL over stored procedures. You may find some benefits in some of the
more cursory aspects of DDD,and perhaps using some of the terminology,but trying to make
DDD fit here will not be a pleasant experience.
以及这一个：
Probably 95% of all software applications fall into the “not so good for using DDD” categories.
Most are fundamentally Data Centric – most websites are,most desktop applications are …
fundamentally most data updating and reporting applications are data centric.
所以你怎么看？
你接受这个意见吗？
根据这些段落,我们不能将DDD用于广泛的IT项目,我们可以吗？
解决方法
首先,(遗憾的是)少数开发人员理解的是,DDD完全是一种心态,一种看事物的方式.而已.因此,您可以在每个项目中使用DDD,因为我们仍然需要首先了解域,无论其实现如何.如果事实证明域只是一堆数据结构,那么你不需要让生活复杂化.特别是如果你正在构建一个’哑’应用程序,即数据库的UI.
但是,如果您正在构建一个需要了解业务语义(概念和行为)以便自动化的应用程序,那么这是一个不同的故事,所有这些DDD概念将帮助您构建一个更易于维护的应用程序.
因此,它在很大程度上取决于您的应用程序,即使在该应用程序中,事情也会有很大差异.您应首先了解应用程序的用途,然后了解它尝试表示的域(如果是这种情况),并为每个用例提供解决方案.在一个应用程序中,你可以拥有很多CRUD的东西,你可以非常有效地省去许多抽象,你可以有一些重要的概念和用例需要更好的理解和设计.您认为应用程序随时间变化的程度也很重要.如果有迹象表明它会随着时间的推移而发展,那么抽象一些东西可能会更好,但这只是从设计的角度来看.此时的实现仍然可以是CRUDy.
如果您将方法论视为一组思维模式和概念,您可以在任何地方使用它,因为像DDD这样的东西不是“如何”编码方法.虽然它有一些特定的工具,但是,应用设计师应该决定它们是否适合您的应用.
简而言之,您必须使用DDD来确定(整个)DDD是否可用于您应用的某些部分.但再一次,DDD意味着战略方法,即思维方式.
从一开始就为整个应用程序决定解决方案是完全错误的.了解应用尝试解决的问题,并针对每个问题使用正确的解决方案.如果最终一切都只是CRUD,那就没关系.如果只使用DDD战术工具实现某些部件同样可以,那就是为问题提供最佳解决方案.
总而言之,学习并理解DDD思维模式(有很多解释,关注设计,而不是因为它们是错误的,所以不要考虑它是一个编码配方,只是使用它来确定最佳方法)满足应用程序的需求.
