Mas*_*ghi 11 domain-driven-design
我一直在读关于这段我遇到的DDD
对于以数据为中心的操作,您可能最好使用Active Record模式,甚至是存储过程的DAL.您可能会在DDD的一些更粗略的方面找到一些好处,也许可以使用一些术语,但尝试使DDD适合这里将不会是一个愉快的经历.
以及这一个:
可能95%的软件应用程序属于"使用DDD不太好"的类别.大多数基本上是以数据为中心的 - 大多数网站都是,大多数桌面应用程序......基本上大多数数据更新和报告应用程序都是以数据为中心的.
所以你怎么看？你接受这个意见吗？根据这些段落,我们不能将DDD用于广泛的IT项目,我们可以吗？
Mik*_*eSW 17
根据作者的经验将这些数字简单地视为一些价值(埃文斯的书出版超过13年前,事情发生了变化).
首先,(遗憾的是)少数开发人员理解的是,DDD完全是一种思维模式,一种看待事物的方式.而已.因此,您可以在每个项目中使用DDD ,因为我们仍然需要首先了解域,无论其实现如何.如果事实证明域只是一堆数据结构,那么你不需要复杂化你的生活.特别是如果你正在构建一个'哑'应用程序,即数据库的UI.
但是,如果您正在构建一个需要理解业务语义(概念和行为)以便自动化的应用程序,那么这是一个不同的故事,所有这些DDD概念将帮助您构建一个更易于维护的应用程序.
因此,它在很大程度上取决于您的应用程序,即使在该应用程序中,事情也会有很大差异.您应首先了解应用程序的用途,然后了解它尝试表示的域(如果是这种情况),并为每个用例提供解决方案.在一个应用程序中,你可以有很多CRUD的东西,你可以非常有效地省去许多抽象,你可以有一些重要的概念和用例需要更好的理解和设计.同样重要的是你认为应用程序会随着时间的推移而改变多少.如果有迹象表明它会随着时间的推移而发展,那么抽象一些东西可能会更好,但只能从设计的角度来看.此时的实现仍然可以是CRUDy.
如果您将方法论视为一组思维模式和概念,您可以在任何地方使用它,因为像DDD这样的东西不是"如何"编码方法.虽然它有一些特定的工具,但是,应用设计师应该决定它们是否适合您的应用.
简而言之,您必须使用DDD来确定(整个)DDD是否可用于您应用的某些部分.但再一次,DDD意味着战略方法,即思维方式.
从一开始就为整个应用决定解决方案是完全错误的.了解应用尝试解决的问题,并针对每个问题使用正确的解决方案.如果最终一切都只是CRUD,那就没关系.如果只使用DDD战术工具实现某些部件同样可以,那就是为问题提供最佳解决方案.
总而言之,学习和理解DDD思维模式(有很多解释,关注设计,而不是因为它们是错误的,所以不要考虑它是一个编码配方,只是使用它来确定最佳方法)满足应用程序的需求.
DDD 是思想的集合。当你说，使用它时，我不确定你指的是什么。例如，如果您要将业务映射到代码中，那么通用语言可能是一个好主意。 值类型也很有用。
但是像有界上下文和聚合根之类的想法？好吧，以这种风格进行开发会产生更大的成本，因为设计自然会变得更加复杂。而在一些问题域中，需要隔离域问题。那是因为这个问题很难。换句话说，95% 的系统不能解决需要复杂性成本的难题。
我喜欢将 DDD 视为存在于某种设计范围内。
就像是：
<--CRUD----Active Record----Domain Model----DDD-->
从左到右，这些想法变得越来越复杂。当您改进代码的设计时，您会自然而然地从左移到右。尽可能晚地推迟有关设计（架构）的决定是一种很好的做法。所以，你总是可以从左边的东西开始，然后向右移动。