uzu*_*zul 4 architecture database-design design-patterns software-design
我们正在开发一个面向服务的大型多层应用程序,必须从头开始设计.现在我们需要开始编程,并尝试组装第一块砖.
问题是从哪里开始？有人建议我们应该从设计持久数据模型开始,这将提供更清晰的视图.这是一个好方法吗？
编辑为Suirtimed
这里没有太多的敏捷文化.这是一个SOA样式项目,使用WCF,SQL Server,实体框架(使用POCO生成器用于域对象),ASP MVC和Workflow Foundation.我们是一个由4名开发人员组成的团队; 技术合理(但不是专家).
我一直试图遵循的广泛的整体方法是从设计领域模型开始.这是您的"普遍存在的语言",它将定义业务对象和概念,包含业务逻辑(稍后,当您拥有它时),并且通常是整个系统各部分使用的通用语言.
这个想法是每个参与者都应该理解(或至少可以理解).例如,某些其他部门的经理不一定会理解关系数据库或其他任何关于在其中保存部门数据的事情.但他确实了解他所在部门的业务流程.他们的白话,他们的概念,他们的互动等.无处不在的语言是群体共有的共同点.
在此过程中,您应该将依赖关系放在首位.最大的一个通常是数据持久性.有一个金色的梦想,领域模型通常是持久性 - 无知或依赖 - 无知,并且为了分离关注点,这是一件好事.然而,真正的依赖性无知会让你陷入困境.您可能会遇到一些严重的性能问题或架构问题,需要在以后进行大量的重新设计.
因此,偶尔从域建模中脱离思考持久性(以及其他外部依赖性,例如需要使用的外部服务或需要集成的第三方应用程序).在为域建模时,请确保模型仍能正常运行所需的一切.你可能不得不在这里和那里对普遍存在的语言做出一点妥协,以适应依赖的局限性.
基本上,在设计数据库之前设计域模型.但是在此过程中不要忘记数据库.