|
锁定老贴子 主题：项目笔记：命名，分层，文档以及细节
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
时间：2007-05-26
Author：Anders小明. 0. 业务分包. 在package命名上，摈斥了Appfuse以及SpringSide中出现的model, service以及manager等技术名词,取而代之的是业务名词和动词,使得行为和模型物理上内聚。我们以为对于开发人员来说，通过包名以及类名获取其业务功能远比了解其技术分类更有助于设计和开发。 这里借用springside的package前缀: org.springside.insurance.product 1. 抽象分层 业务是有抽象层次的. 往大的方面，可以见《Domain Model：基于抽象的分层结构》。这里只往小的方面说，比如保险中accident就拥有自己独立的业务概念和行为，并且这些概念和行为是紧耦合的。我们的目标是类似这样的业务抽象层次，我们只要发布相应的类和资源文件就可以在服务器上热部署。包的命名结构如下： org.springside.insurance.accident.contract 当然可能有朋友说：我也可以这样命名，一样可以达到同样的目的。 org.springside.insurance.contract.accident 的确如此，对计算机或者jvm来说没有区别，它不管怎么命名。但是程序是写给人阅读的，我们希望在命名上能够尽量提供信息和暗示。我们以为，上一种命名方式更容易阅读，同时能给出紧耦合的暗示。
2. 技术职责分层 减少不必要的技术职责层次. 尤其是减少了Web层的VO. Web层直接访问Domain Model. 当然关于这点在技术上有过很多讨论. 我只想说的: 是否建立VO的题关键在于边界的确立, 建立边界的情况有两种:人员分工以及边界双方存在替换可能. 通常意义上Web和Domain都是一个人开发的,没有特别分工(也有可能不是同一个但没有出现并行开发, 美工除外)，即便此时强制要求设计VO，也会发现设计出来的VO和model非常的类似，但增加了不必要工作量，包括copy属性操作，以及null处理（是页面没有提交该值，还是user要清空该值）; 同时很少存在Web不替换而替换后台Service以及Model的情况. 因此我们可以得出一个结论：页面依赖于模型. 这样系统需要写代码的只有Service和Model两类对象 还有一个类对象，传统的Dao，这类对象比较麻烦。采用DDD中提出的Aggregate模式，把domain模型区分开来。Domain Model利用主对象作为root，游走访问其关联对象，减少dao爆炸，使OLTP中的dao保持在较少的一个层次；对于Report或者OLAP则利用其它SQL保持性能。（关于这块目前的没有遇到大的问题，不算成功了，还在尝试中） 3. 业务职责设计模块 主要工作在模块间的交互接口设计：适应性接口和公共接口分离。 (原则:不要以用户无法使用或不感兴趣的东西扰乱类的公有接口). 在我的另一篇blog《模块的接口设计》中有描述.
4. 代码和文档的统一。 文档的维护一直是比较麻烦的问题。尝试通过Annotation等元数据来帮助我们简化工作。 首先Annotation能够提供的信息有三个级别：代码级别（IDE支持, JavaDoc），编译级别（编译器支持，代码生成），运行时级别（框架反射）。尤其是后两种，既是设计又是代码。除此外Spring的XML还包括很多信息，例如事务声明，Web Flow的页面流程信息等。 尝试通过应用更多既是设计又是代码的元数据，在借助一定手段收集这些信息，减少在文档上的工作量。
5. 设计上的细节 在Service对象的设计上。按model是骨架, service是肌肉,而rule是神经的职责分类.service对象的设计以行为为主线,利用template模式把rule做一定分离。另一个原因是系统应用了规则引擎，采用这样的设计有利于单元测试。 声明：JavaEye文章版权属于作者，受法律保护。没有作者书面许可不得转载。
|
| 返回顶楼 | |
|
时间：2007-05-26
IMPO
对于系统设计，你有过度使用OO之嫌 系统中，通常并不是一个每一点都是OO的，Transaction Script设计和OO设计会在系统中同时存在 所以， 引用 在package命名上，摈斥了Appfuse以及SpringSide中出现的model, service以及manager等技术名词,取而代之的是业务名词和动词,使得行为和模型物理上内聚。我们以为对于开发人员来说，通过包名以及类名获取其业务功能远比了解其技术分类更有助于设计和开发。
实在看不懂所谓使得行为和模型物理上内聚 是什么意思。 在我看来分Model,Service和Manager是有意义的， Model层你大可以采用OO思想设计你的Domain Model， Service层往往会面向Transaction，用来组织具体的Domain Object，并调用持久化逻辑。 Manager层通常会完成Transaction的，Security等控制，还会组织Presentation Layer需要的数据 所以，我并不完全确定你的包结构所要表达的东西 org.springside.insurance.product org.springside.insurance.product.manager org.springside.insurance.product.service org.springside.insurance.product.model 和 org.springside.insurance.product.manager org.springside.insurance.product.manager.product org.springside.insurance.product.service org.springside.insurance.product.service.product org.springside.insurance.product.model org.springside.insurance.product.model.product 没有太本质的区别 对于你的技术职责分层说法 给我的感觉的太含糊，因为就算你废除VO，直接暴露Domain Object给Web层其实也有多种方式 你是采用OpenSessionInView呢？还是采用Detached Domain Object?还是传递一个封装过的Domain Object? 说白了，系统架构设计的Decisions make时，需要想到方方面面，而不是单纯从简单，方便，少写几个DTO/VO这个单点考虑 引用 通常意义上Web和Domain都是一个人开发的,没有特别分工(也有可能不是同一个但没有出现并行开发, 美工除外)
对于大型项目，分层开发是一个趋势，现在没做，并不代表以后不做 引用 同时很少存在Web不替换而替换后台Service以及Model的情况. 因此我们可以得出一个结论：页面依赖于模型 .
太多例子了，事实上，对于一个系统而言，在很长的一个生命周期内，它们二者都不会是稳定的，可能有一段时间，大家觉的改重新设计业务模型了，而某一段时间，大家觉的该重构页面和页面流程了 最好不要妄下结论，逻辑上依赖，并不一定代表物理上直接依赖。物理上解藕页面模型和业务模型对于复杂以及生命周期比较长的系统是很重要的 Thanks |
| 返回顶楼 | |
|
时间：2007-05-27
引用 实在看不懂所谓使得行为和模型物理上内聚 是什么意思。 在我看来分Model,Service和Manager是有意义的， 看来我表达的确不到位！在想该怎么表达好！ 引用 所以，我并不完全确定你的包结构所要表达的东西 org.springside.insurance.product org.springside.insurance.product.manager org.springside.insurance.product.service org.springside.insurance.product.model 和 org.springside.insurance.product.manager org.springside.insurance.product.manager.product org.springside.insurance.product.service org.springside.insurance.product.service.product org.springside.insurance.product.model org.springside.insurance.product.model.product 没有太本质的区别 上一个和下一个都不是我的分包结构，都是你写的。 引用 说白了，系统架构设计的Decisions make时，需要想到方方面面，而不是单纯从简单，方便，少写几个DTO/VO这个单点考虑
我的观点，系统设计就是一个：简单，让开发人员简单。我反对复杂的方案，就web的vo来说，我看不到它存在的好处。你可以要求一定要搞个vo出来，实际的工作中，开发人员一定和做的和模型类似，一是同一个人设计思路问题，另一个是理解问题，再一个是属性COPY方便性。即使这样，也会带来很多属性复制上的问题，而在模型变化时带来了额外的工作量。 引用 对于大型项目，分层开发是一个趋势
什么样的分层开发是趋势？传统的J2EE吗？我的理解是，分层和分模块都只是一种确立边界的手段。对于WEB层来说，我感受到的是其在模型上独立性的意义不是很大。可能这点上我的理解不正确，同时也和开发流程相关：先设计模型，在设计服务，最后设计UI。 引用 现在没做，并不代表以后不做
拿可能性来压人？好吧，我不敢说一定不会，但是我考虑的是概率问题，从我了解到信息，以及工作上的经验来看，这个可能性为零。当然这个可能是我的错觉，如果你能告诉我真相，不甚感激。 引用 太多例子了，事实上，对于一个系统而言，在很长的一个生命周期内，它们二者都不会是稳定的，可能有一段时间，大家觉的改重新设计业务模型了，而某一段时间，大家觉的该重构页面和页面流程了
太多例子？好吧，是我孤陋寡闻了，麻烦你告我有那些例子（顺带提下背景最好）。另外还是那句话，考虑一下概率问题，在我接触到信息中，无论是重新设计业务模型还是页面，都是以模型为主，调整页面的；这其中包括了vo的调整，主要的原因在于VO的设计上类似于模型，以方便属性COPY。另外，这可能是一种错觉，我认为保留WEB，而替换模型的概率很低，并接近于零，我不想在最初的开发中为这样一个小概率事件做大量额外工作，那样对我来说roi不划算 |
| 返回顶楼 | |
|
时间：2007-05-27
引用 我的观点，系统设计就是一个：简单，让开发人员简单。我反对复杂的方案，就web的vo来说，我看不到它存在的好处。你可以要求一定要搞个vo出来，实际的工作中，开发人员一定和做的和模型类似，一是同一个人设计思路问题，另一个是理解问题，再一个是属性COPY方便性。即使这样，也会带来很多属性复制上的问题，而在模型变化时带来了额外的工作量。
我的认为,简单,复杂,不能从单从某一点去考虑,不同的应用也对复杂,简单的要求不同. 而且,框架内部的复杂,并不意味着对外开放给开发人员的接口是复杂的,很多工作,框架可以处理掉,它所带来的好处是整个系统的一致性,在需求变化时表现出良好的适应性 即使你提供一个你所谓的"简单"方案,你也需要同时给出由于"简单"而带来功能,架构上的缺陷的解决方案,你给一个比较全的方案,也许你会觉的你的"简单",也许并不简单 引用 什么样的分层开发是趋势？传统的J2EE吗？我的理解是，分层和分模块都只是一种确立边界的手段。对于WEB层来说，我感受到的是其在模型上独立性的意义不是很大。可能这点上我的理解不正确，同时也和开发流程相关：先设计模型，在设计服务，最后设计UI。
分层开发能够强迫各个层提供清晰的接口,在项目比较大,或者产品开发模式下,是有很重要的意义的.而按模块开发,通常达不到这样的效果. 当然这整个开发模式的改变应该是一个渐进的过程,而不是一步跳跃 引用 太多例子？好吧，是我孤陋寡闻了，麻烦你告我有那些例子（顺带提下背景最好）。另外还是那句话，考虑一下概率问题，在我接触到信息中，无论是重新设计业务模型还是页面，都是以模型为主，调整页面的；这其中包括了vo的调整，主要的原因在于VO的设计上类似于模型，以方便属性COPY。另外，这可能是一种错觉，我认为保留WEB，而替换模型的概率很低，并接近于零，我不想在最初的开发中为这样一个小概率事件做大量额外工作，那样对我来说roi不划算
参加的几个项目会议,基本上都是UI尽量保持不变,重构业务模型. 其实在在开发阶段,先模型,再页面的情况可能占大多数,但也不是绝对的,很多情况下,做页面前,并不需要有很成熟的业务模型. 而在升级阶段,都不会有很明确的谁先谁后,往往都是按阶段,按计划,按重要性分配任务 |
| 返回顶楼 | |
浏览 2095 次
