02 2014 档案

.NET应用架构设计—面向查询的领域驱动设计实践（调整传统三层架构，外加维护型的业务开关）

摘要：

DomainModel是由很多细粒度的Object组成，按照以往的教训（将Object行为、数据肢解，得到一个残缺的Object），现在我们将逻辑行为和数据绑定在一起，形成了一个丰富的领域模型，这也是面向对象设计原则之一；想了解更多关于实现面向对象的技巧请参考【《实现模式》作者：Kent Beck】一书；但是这样又带来了由于充血型DDD模型会给面向大规模查询的业务模块带来一定的性能开销，试想一个OrderManager对象，如果我们需要获取在某个条件范围类的所有Order会给OrderManager带来很多性能、逻辑上的复杂度；根据DDD.CQRS架构，得知将DomainModel中的查询逻辑单独剥离出去，让Command端很干净的处理聚合的写逻辑，在Query端也很直接的处理查询逻辑；阅读全文

posted @ 2014-02-16 12:04 王清培阅读(4788) 评论(6) 推荐(10) 编辑

.NET应用架构设计—面向查询服务的参数化查询设计（分解业务点，单独配置各自的数据查询契约）

摘要：

现在越来越多的公司都在尝试SOA架构的实践，本人最近也在尝试学习这方面的技术，但是在实践过程中遇到一个问题，我想这个问题也是我们普遍实践者都应该会遇到的问题，问题描述如下：我们有一个SOA商品（Item）查询接口，这个接口很通用，主要用来支撑日常很多其他系统的大量关于Item的查询，尤其是在高峰期间该服务的压力是很大的；我们站在SOA的角度看这个接口，这个通用的接口解决了众多的查询业务，确实不错，但是我们切换一下角度，站在每一个调用接口的访问端看似乎并不是很满意或者说牺牲了部分性能上的代价，因为我们无法干净利落的只获取当前这个业务点需要的数据项；这个Item服务接口所返回的数据项必须同时满足所有调用它的业务点，哪怕这次调用我只需要用到Item的三分之一的数据字段都不行，每次都会把不需要的字段都查询出来，不管是返回的性能、查询的性能，其实都是可以通过调整设计来避免的；阅读全文

posted @ 2014-02-06 18:47 王清培阅读(5244) 评论(16) 推荐(7) 编辑