移动开发中的领域模型

      最近在做保险行业的iPad客户端应用，在项目过程中引入了领域模型设计和MVC的设计思想，引发了一番争论。从实践过程来看领域建模更多的是一种分析和设计业务模型的一种方法。由于在ios开发中并没有像J2EE开发企业应用这样成熟的开发框架，MVC更多的应用在表现层的开发，UIViewController严格来划分应当都属于View（视图层），这也不怪苹果在ios上更多是针对小应用或者游戏的开发的精简版。

      个人认为不论在实际开发中是否引入领域模型层，都可以采用领域模型来分析业务，而在实际开发中领域模型层和J2EE现在广泛采用的Service层有相似之处。都是对业务逻辑的封装，Service层的引入来自于Controller层和贫血型模型层，由于随着业务逻辑的复杂度提升，Controller除了处理应用逻辑同时处理领域逻辑，造成Controller过重，从而将通用的业务逻辑提取出Service层作为封装和复用。贫血的模型从实际开发中更多是基于表的开发模式，从设计库表作为项目的核心，辅以业务流程图，最终实现为一个一个的Service。而领域建模从设计开始不关心数据存储和表现层，而是将业务模型抽象成一组相互协作的领域类，在类与类之间运用各种面向对象技术，使实际的业务映射成为类与类之间的关系。

      在我们的实际开发过程中，大部分的和数据相关的都不是数据库存储的，更多的是接口的调用。在系统中实现业务逻辑的方法有很多，常用的Service＋实体类起到了领域模型是起到同样的作用的，至于谁好谁坏，我觉得每个人的视角不同，做惯了J2EE的我想更容易接受Service＋实体类的模式。

      关于领域模型，100个人有101种领域模型，很难说谁的好谁的不好，只存在谁的好用谁的不好用。同时我们看到实际开发过程是一个除了代码，系统架构也在不断重构的过程。

      在客户端开发过程中使用领域驱动是否大材小用了呢？我觉得一个领域驱动是一种习惯，一旦掌握了就不太愿意采用其他的设计方法，即使它的业务逻辑很简单。第二，领域建模是一种设计方法，与具体的开发架构没有必然的联系，团队可以选择自己熟悉的开发框架来做。

        写的有些乱，全当给自己备案，有机会把实际项目中的设计总结一下。