领域驱动设计 - 技术领域的相关性如何？

这是一件让我误解DDD的事情.在处理具有复杂模型的非技术业务领域以及技术人员和非技术领域专家之间需要大量交互时,我可以清楚地看到该方法的好处.

但是,当涉及的"域名"是技术时呢？

例如,情况A)采取网络启动.想象一下,他们正在努力完成一些相当复杂的事情(比如一个facebook克隆),但几乎所有的员工都是技术人员(或者至少有很强的技术理解力).

情况怎么样B)类似的情况,但有一个稍微不那么雄心勃勃的项目,以及一个单独的开发人员试图创建一个优雅的架构的东西.

我真的很想听听人们说些什么.我真正想要的是,DDD的好处在哪里,缺点可能是什么,以及在什么程度上比一个更重要......

DDD实际上只是对Fowler 在企业应用程序架构模式中称为域模型的设计模式的详细阐述.在那本书中,他将领域模型与其他组织代码的方式进行了比较,例如事务脚本,但很明显,除了最简单的应用程序之外,他更喜欢领域模型而不是其他选择.我也做.

DDD简单地扩展了领域模型的原始概念,并提供了大量关于如何以对开发人员有益的方式分析和建模我们的领域的指导.

如果有问题的域很复杂,那么域模型(以及DDD)是一个不错的选择.域名是面向业务还是技术性质并不重要.在他的" 领域驱动设计"一书中,Eric Evans首先描述了DDD技术如何帮助他模拟印刷电路板应用.这肯定是一个技术领域,如果有的话!

在我目前的工作中,我们使用DDD来模拟处理基于声明的身份的应用程序 - 另一个非常技术性的域.

DDD实际上只是处理软件的复杂性,这也是埃文斯的书的副标题:"解决软件核心的复杂性".