1、常规以类图作为领域模型开发存在的问题
传统型以技术为驱动的团队,往往喜欢通过类图来展示产品的模型,这样的模型往往存N个对象,这些对象往往存在复杂的关联,产品的创始人,可能能理解整个产品的架构思路,但是如果是新成员...而且假设这个类图代表的领域模型是正确的,但是当团队真正的去实现这个模型的时候,发现还是无法将这种错综复杂的模型转换成可存储可转换的事务单元.这里需要解释下,因为前面的文章介绍了,最小化抽象领域的概念,这是领域驱动设计的必然要求...领域模型种类很多,他们的目的也各有不同,且领域驱动设计要求,模型不仅能够指导前期的分析工作,而且还应该成为设计的基础,我们的代码也必须是结合模型的....各做各的事情.但是这个过程很艰难,需要长期的头脑风暴,有些甚至不可能.但是必须得这么做.否则随着时间得推移,产品会渐行渐远.
4、面向对象语言得优势(C#)和Model-Driven Design(模型驱动设计...而不是由IE自行处理,这样用户就变得非常的弱势,那么软件的用户可能随之减少.
6、模型驱动对于开发人员的重要性
如果在项目开发种架构师只负责搭建核心驱动程序的模型,而不参与业务模型的搭建,任由手下的开发随笔的去构建业务模型