2014-03-25 20:33 by 破狼, 2465 阅读, 收藏, 编辑
在软件开发设计中我们经常会面对业务分析，提取领域问题，从而实现软件架构设计。关于 软件架构设计Martin Fowler在2004出版的《企业应用架构模式》中 概括了四种方式的架构模式。它们分别为事务性脚本，表驱动模式，活动记录模式，领域驱动设计。前两者事务性脚本，表驱动模式作为 面向过程方式架构设计，后两者为面向对象架构设计。它们适合于不同的业务场景，它们也各有长短。事务脚本模式事务脚本模式是架构设计中最简单的架构模式，面向过程模式。该模式以用户的操作，UI表现为起点，设计业务组件， 即业务逻辑将直接映射到用户界面的操作。这通常是从表现层逻辑出发，表现层需要什么那么业务层就提供什么， 直到数
2013-05-29 21:11 by 破狼, 1662 阅读, 收藏, 编辑
最近某同事抱怨他们的测试难写，经常花费在测试的时间比产品代码更多，而且每次重构后都必须修改一大堆的测试。和同事闲谈后得知，在其项目中大量的使用了mock，或者说对mock的使用过度极端对所谓的单元测试“快速”，“独立“的过度。 在前边转载过《软件开发中没有所谓正确的方法》，当你把某一种方法论作为银弹使用的时候，早晚魔鬼会伴随在你身边。 Mock给我带来了感知，剥离了类与类之间的依赖，有助于我们更好的工作在当前的关注点 .但同时由于太多的对场景的假设，导致这块代码成为了信息的孤岛，甚至很多时候不得不用mock的第二特性verify，order，以至于你的测试关心的不再是代码存在的busin...
2013-05-07 09:44 by 破狼, 1820 阅读, 收藏, 编辑
忙碌了一年了项目又到了交付了，虽然项目能成功上线（因为还有维护支持的团队）。但是个人从技术上看，这是一个不那么成功的项目，因为后期艰难的修复bug,添加feature。这与简单设计有什么关系呢？在某模块开发起初，由于架构的经验预见性的告诉我这模块开发中会出现什么问题，所以选择了提出某些比较好的解决方案，但是由于团队成员一致的所谓简单设计，通过TDD,重构达到”合适”的”完美”的设计，可是最后的结果如我所料一切的发生。这里插一句，现在在一家敏捷公司，敏捷强调是合作，所以没有一个人统一规划决策，不同之前的公司作为架构师决策一切架构设计。敏捷合作交流我不否认你正确性，因为我也相信软件是人和时间的问.
2013-03-24 17:08 by 破狼, 41754 阅读, 收藏, 编辑
在去年到今年参与了2个使用Angularjs作为客户端开发框架的项目开发。主要利用asp.net web api作为restfull服务提供框架和angularjs结合。Angularjs作为html的扩展，旨在建立一个丰富的动态web应用，通过Directive建立一套html扩展的DSL模型，利用PM模式变形MVVM（在网上很多称MVC模式，本人认为在angular0.8是属于经典MVC模式，但在1.0把scope独立注入过后，更倾向于MVVM模式，这将会后续随笔中写道）简化前端开发和使得前端业务逻辑得以分离，view和表现逻辑的分离，更便于维护，扩展。Angularjs本来就是采用TD.
2012-10-28 16:45 by 破狼, 2575 阅读, 收藏, 编辑
至今Aspect Oriented Programming已经被开发人员所熟知，其简写AOP，译为面向方面编程（也有称面向切面编程）。其产生于90年代Xerox PARC实验室编程范式。被称为oop的延续，oop主要针对业务处理过程的领域问题抽象封装，形成领域对象，更好的描述自然领域问题。而aop主要处理业务处理过程中处理逻辑步骤分离，减少业务逻辑的耦合性，是的我们的开发人员在开发过程中只需关心领域的核心实际逻辑。在结构化编程（SP）中提出了SOC(分离关注点)，并一直被称为是面对复杂软件最行之有效的方法之一，并被努力应用于不同的软件实践，比如表现层模式MVC，MVP，PM，面向服务编程SO.
2012-07-31 22:11 by 破狼, 7516 阅读, 收藏, 编辑
现在的软件系统开发难度主要在于其复杂度和规模，客户需求也不再像Winston Royce瀑布模型期望那样在系统编码前完成所有的设计满足用户软件需求。在这个信息爆炸技术日新月异的时代，需求总是在不停的变化，随之在2001年业界17位大牛聚集在美国犹他州的滑雪胜地雪鸟（Snowbird）雪场，提出了“Agile”（敏捷）软件开发价值观，并在他们的努力推动下，开始在业界流行起来。在《代码整洁之道》（Clean Code），提出一种软件质量，可持续开发不仅在于项目架构设计，还与代码质量密切相关，代码的整洁度和质量成正比，一份整洁的代码在质量上是可靠的，为团队开发，后期维护，重构奠定了良好的基础。在这.
2012-07-12 23:16 by 破狼, 2532 阅读, 收藏, 编辑
最近在上下班挤公交的时间细阅Clean Code（代码整洁之道），再次佩服Bob大叔幽默的文笔，独到的观点和理解视角。最让我耳目一新的是Bob大叔对数据结构和对象的解释。 总的说来数据结构指的就是数据的载体，暴露数据，而几乎没有有意义的行为，你应该在尖叫这不是贫血类？的确这和我们的贫血类很相似。最常见的应用在分布式服务，以wcf，webservice，reset之类的分布式服务中不可或缺的数据传输对象（DTO）模式，DTO（Request/Response）就是一个很典型的数据载体，只存在简单的get，set属性，并且更倾向于作为值对象存在。而对象则刚好相反作为面向对象的产物，必须封装隐...
2012-07-07 15:02 by 破狼, 3671 阅读, 收藏, 编辑
在前面简述了从服务层到数据层参见架构设计目录。剩下了表现层，一个再好的中间层表现也必须有一个用户界面，提供和用户交互，将用户行为输入转化为系统操作，进入后台逻辑。在当下RAD（快速应用开发）工具的支持下，我们可以比较快速的完成UI设计，RAD追求所见即所得的快速反馈，快速应用。表现层也有一定其固定的逻辑（格式化，数据绑定，转化等等，称为UI逻辑）和界面展现。这里UI逻辑指的是所有用来处理数据显示在UI界面的逻辑和，将UI用户输入行为转化为中间层指令的逻辑，负责UI和中间层数据流和行为的转化。很多时候UI是最容易变化的以及最不易测试的逻辑（我一直相信，1：一段好的代码一定要易于测试。2：重构的.
2012-06-24 22:57 by 破狼, 2238 阅读, 收藏, 编辑
这篇随笔由于出差拖了很久，一时也没整理好该写些什么。在google搜了下“存储过程 优劣”关键字，资料并不多，出现了一篇关于来至51cto的关于存储过程的优缺点的文章，具体这里也不指出了。看见文章中对存储过程的几个辩解，个人不敢苟同，个人已经很仔细的看了文章的时间是2011年，如果在更前写年成的话，个人觉得完全能够理解。所以有了这篇，存储过程的一些传言。 1：存储过程只在创造时进行编译，以后每次执行存储过程都不需再重新编译，而一般SQL 语句每执行一次就编译一次,所以使用存储过程可提高数据库执行速度。 在sql server 2000版本，这个观点没错，却是如此。但是在sql ser...
2012-06-06 08:11 by 破狼, 4291 阅读, 收藏, 编辑
架构引用维基百科：软件体系结构是构建计算机软件实践的基础。与建筑师设定建筑项目的设计原则和目标，作为绘图员画图的基础一样，一个软件架构师或者系统架构师陈述软件构架以作为满足不同客户需求的实际系统设计方案的基础。从和目的、主题、材料和结构的联系上来说，软件架构可以和建筑物的架构相比拟。一个软件架构师需要有广泛的软件理论知识和相应的经验来实施和管理软件产品的高级设计。软件架构师定义和设计软件的模块化，模块之间的交互，用户界面风格，对外接口方法，创新的设计特性，以及高层事物的对象操作、逻辑和流程。 软件架构师与客户商谈概念上的事情，与经理商谈广泛的设计问题，与软件工程师商谈创新的结构特性，与程序..
2012-06-05 00:13 by 破狼, 5743 阅读, 收藏, 编辑
在前面简单描述了下服务层，SOA面向服务架构，架构设计-业务逻辑层，以及一些面面向设计原则理解和软件架构设计箴言。这篇博客我们将继续进入我们的下一层：数据访问层。无论你用的是什么开发模式或者是业务模式，到最后最必须具有持久化机制，持久化到持久化介质，并能对数据进行读取和写入CRUD。这就是数据访问层。你可能是利用xml等文件格式磁盘存储，常用的关系数据库存储，或者NoSql(not only sql)的内存存储或文档存储等等存储介质。而这里我只关心关系数据库存储。 数据层需要提供的职责有： 1：CRUD服务。作为唯一可以与存储介质交互的中间层出现，负责业务对象的增加，修改，删除，加载...
2012-06-02 21:30 by 破狼, 10398 阅读, 收藏, 编辑
今天和师弟聊天聊到他们项目开发，有些同事总是提前考虑性能优化，需求变更又是一大堆的重写，让我想起了Donald Knuth 提到的：对软件的过早地优化是万恶的根源。这里就简单的说几条重要的软件名人哲学。1：软件中唯一不变的就是变化。 在软件开发过程中需求是不停的变化，随着客户对系统的认识，和现有开...
2012-05-29 23:14 by 破狼, 7648 阅读, 收藏, 编辑
业务逻辑层是专门处理软件业务需求的一层，处于数据库之上，服务层之下，完成一些列对Domain Object的CRUD，作为一组微服务提供给服务层来组织在暴露给表现层，如库存检查，用法合法性检查，订单创建。 业务逻辑层包含领域对象模型，领域实体，业务规则，验证规则，业务流程。1：领域对象模型为系统结构描述，包含实体功能描述，实体之间的关系。领域模型处于天生的复杂性:2：领域实体：业务层是一些操作业务对象（BO）的处理。业务对象包含数据和行为，是一个完整的业务对象。其不同于上节架构设计中服务层的简单理解提到的数据迁移对象（dto），对于dto存在数据的，不存在行为，dto是bo（ddd中又称...
2012-05-27 22:33 by 破狼, 5813 阅读, 收藏, 编辑
这里要介绍一款与企业库VAB(Validation Application Block)，ASP.NET MVC基于Attribute声明式验证所不同的验证组件，FluentValidation，其利用表达式语法链式编程，使得验证组件与实体分开。我喜欢他的原因是喜欢表达式，喜欢链式的感觉，大有一气呵成之意。 进入今天的主题首先如果你还没有这款组件，你可以利用VS2010的NuGet安装，（如果不会的请安装上篇开源DataBase组件：FluentMigrator中提到的方式安装），命令为： 现在我们可以开始体验了，实体类do任然是上节的Orders： do：publiccl...
2012-05-27 19:09 by 破狼, 2958 阅读, 收藏, 编辑
今天将介绍一款开源组件FluentMigrator，其提供了jQuery式链式编程方式，和3.0后的表达式语法使其语义清晰。主要提供我们队数据库结构的维护，版本控制回滚和新增。适用于 敏捷和TDD实践中我们的需求功能的递增，数据结构增加，可持续化集成，应用场景感觉如其名Fluent（流畅）。 一：我们先利用NuGet安装FluentMigrator： 1：在vs在打开Package Manager Console： 2：安装FluentMigrator： 3：如果你希望控制台提交，可以安装其tools： 二：下面我面做一个简单的实例订单Order（这里仅列...
2012-05-22 21:37 by 破狼, 5228 阅读, 收藏, 编辑
在上篇中我们简单谈了下架构设计中服务层的简单理解，在这里我们将继续服务层的架构，在本节我们将重点在于分布式服务。在分布式系统中表现层和业务逻辑层 并不处于同一物理部署，所以我们必须存在分布式服务，以契约方式发布于网络中，我们的关注点在于服务，面向服务编程，这种通过组合业务逻辑暴露可用服务的架构叫做面向服务架构（SOA）。 SOA强调一个松耦合，基于宏服务的架构，通过契约暴露给服务消费者可用的服务交互。SOA是以服务为组成构建，原则有： 边界清晰： 服务层是消费者交互到系统业务的唯一入口,所有我们的服务必须能够被消费者所理解,以及最好处理Request/Response基于消...
2012-05-21 23:09 by 破狼, 6674 阅读, 收藏, 编辑
在ddd设计中我们经常会提到服务层，服务层是什么？职责是什么？有什么好处？。 先看简单的层次图（注：这里并没有考虑其他多余的领域逻辑数据层存储，或者UOW这些细节） 我的理解是服务层是处于我的应用程序业务层和表现层之间的应用程序边界,边界可能是很薄的一层类设计或者是分布式服务网络跃点。它是一个与技术无关的名词。由表现层直接调用，契约，执行命令（修改状态（CUD））或者是查询返回dto（数据迁移对象）（cms，命令-查询分离）。他对业务逻辑层接口很清楚，组织业务逻辑 微服务形成宏服务，适配表现层。 这里谈到宏服务和微服务，宏服务有一些列粗粒度的服务组成。用户的一次操作usec...
2012-05-12 18:57 by 破狼, 5374 阅读, 收藏, 编辑
以前本站向大家介绍过一些软件开发的原则，比如优质代码的十诫和Unix传奇(下篇)中所以说的UNIX的设计原则。相信大家从中能够从中学了解到一些设计原理方面的知识，正如我在《再谈“我是怎么招聘程序”》中所说的，一个好的程序员通常由其操作技能、知识水平，经验层力和能力四个方面组成。在这里想和大家说说设...
2012-05-09 22:50 by 破狼, 4762 阅读, 收藏, 编辑
Layer 和Tier都是层，但是他们所表现的含义不同，Tier指的是软件系统中物理上的软件和硬件，具体指部署在某服务器上，而Layer（逻辑层）指软件系统中完成特定功能的逻辑模块，逻辑概念。 Layer是逻辑上 组织代码的形式。比如逻辑分层中表现层，服务层，业务层，领域层，他们是软件功能来划分的。并不指代部署在那台具体的服务器上或者，物理位置。 Tier这指代码运行部署的具体位置，是一个物理层次上的划为，Tier就是指逻辑层Layer具体的运行位置。所以逻辑层可以部署或者迁移在不同物理层，一个物理层可以部署运行多个逻辑层。 从Layer和Tier就会延伸到逻辑架构和物理架构。我...
2012-05-08 00:47 by 破狼, 4627 阅读, 收藏, 编辑
面向对象设计（OOD）核心原则让我的程序模块达到“高内聚低耦合”,这是来自于30年前兴起的结构化设计（structured Design），但是同样适用于我们的OOD。1.高内聚： 高内聚是指某个特定模块（程序，类型）都应完成一系列相关功能，描述了不同程序，类型中方法，方法中不同操作描述的逻辑之间...
2012-02-12 23:28 by 破狼, 5550 阅读, 收藏, 编辑
在当前软件开发OO设计中，面对软件需求的各种潜在变化，我们可能会采用领域驱动开发，把我们的各个业务逻辑分层次隔离解除耦合，这就出现了N层架构（这面值得是逻辑上的分层，当然我们的逻辑分层层次需要比物理架构层次多），这样将会使得我们的软件能够适应更多的需求变化。关于领域驱动开发的实例网上都很多，不得不推荐的是微软开源实例项目的NLayerApp：http://microsoftnlayerapp.codeplex.com/。 然而在于我们的逻辑分层的每一层次之间的耦合度解耦也是一个常见的问题.这样在层次的变化中我们需要实现不变更服务层次，这是我们的设计必须依赖于不变接口（抽象）。对于分层的接口对.
