大多数关于DDD的书籍都谈到了如何使技术与业务保持一致。所以你有订单和支付业务规则等等。
如果我写一个技术应用程序。例如,如果我创作了一个像app这样的visual studio。DDD是否无关紧要,或者我可以说我的领域是“应用程序开发”,并确定参与者(“解决方案”、“文件”)和业务规则,以便我可以应用DDD。
发布于 2010-09-15 05:45:34
这里的情况只是业务领域是技术性的;这不是不使用DDD的理由。
在某些方面,这让它变得更容易了--因为你自动成为了“业务”领域中的一个子对象问题专家(SME)。
在其他方面,这会更难--你可能会发现术语“冲突”。
例如,如果您正在对系统建模,您可能会将技术术语建模,就好像它们是业务术语一样。我们都见过带有名为"Customer“等实体的类图;但是拥有一个名为" class”的实体很快就会导致问题--特别是当你想用它来生成代码的时候。
发布于 2010-09-14 18:56:57
您的技术应用程序的领域应该与系统用户如何谈论它的语言保持一致。因此,使用开发工具,您可以拥有项目、文件、属性等
发布于 2010-09-14 18:55:38
领域驱动设计几乎总是足够的。勇敢点儿。:)另外,看看像http://www.sharpdevelop.net这样的集成开发环境的实现也是个好主意
https://stackoverflow.com/questions/3708144
复制相似问题