架构中的分离
我的一个项目中，引入了一个类似ddd的分析，然后跟兄弟们就搭手创建，实现代码！
但是，在我们创建的过程中，以及不断的分析中，我们发现全部按照ddd来实现有很多比较牵强，或者说是有点复杂化了，在此表述出来跟同行的xdjm们探讨探讨。
我们从最开始就用ddd的模式进行业务分析，找出其中的业务对象：实体、值对象、工厂、仓库、以及类似聚合根的facade对象，用来实现一个简单的表单自定义功能。这个功能里面主要是添加表单对象（形象点就是标签），然后调整这个标签的摆放位置（layout），以及这个标签的各种属性。这个过程中产生的业务就是增删改查，没有多少特别的，唉。。。。
但是我们当初在分析的时候，也是按照ddd的架构(或者说是包结构)方式来实现，增加了很多过程对象（这些对象包括ddd里面的那种分层和对象组，xdjm们可以看看那个ddd sample例子，我忘了地址了，不过在这个论坛里面有）。
等到我们真正分析业务流程的时候，我发现对上面的实现还是有些用处的，因为我们通过上面的增删改查处理过程，可以产生我们业务过程中需要的对象，在这里使用ddd就显得合理了很多。
所以，我就考虑，一个项目中的分析应该划分出两个部分进行实现：一是针对对象的维护（可能就是增删改查，不必实现ddd的那一整套）；一是按照领域的业务处理，在这里面我们可以实现不同对象的管理。这里所讲的对象管理不是简单的增删改查，而是对象的初始化，数据加载等等，体现在ddd里面可能就是factory，repository等等，还有就是entity，vo，在一个业务过程里面，我们可以清楚感觉到一个对象的到底是不是有生命周期，到底是不是一个有特征的特殊对象，从而确定了实体，而我们在处理这些实体的时候就会自然而然的分离出其中的一些聚合根，如果实在找不到，我们可以用facade模式来替代，以避免产生业务泄露的缺口。
而如果我们把上面的两个方面混在一起来处理的话，我们就是在第一种情况里面产生一些迷茫，到底实体在哪里？值对象在哪里？都是增删改查，谈什么实体和值对象啊？如果是那样的话，我们就不是很清楚的分离业务处理和数据维护。。。
针对这些情况，我觉得分离增删改查相当有必要，必要到我想把增删改查用restful来实现，也就是我们的那些跟增删改查相关的页面都有统一的调用和实现机制，区别就是提交的表单，对应的数据库表，所有这些东西我们其实不必做太多工作，但是可能会有很多特例，那样就会增加相应的复杂性了。。。。
业务领域分析就是对象的协作，对象的集成。。。。这点就要具体情况具体分析了。。。。。
小弟在此抛砖引玉了。。。。