|
在《不过时的经典层架构》里讲了经典的四层架构怎样对易变性做封装。咱们实际项目中，如果没有足够的实践和关键性思考，还是很可能使用名义上科学的分类理论，却在按照功能进行架构分层。今天咱们就通过一些简单的指导来尽量减少这种风险。 四问 在架构分层中，分层设计松散地对应着who、what、where、how这四个问题。 who是客户端交互的系统，what是在Manager服务中需要的系统，how是Engine服务中需要的系统，how是访问数据层的工作，where在系统表述中指资源。按照四问重新画一下经典四层架构的架构图是这样的：
问及回答这四个问题，在启动设计及验证设计的时候都很有用。 关键最佳实践 易变性递减原则 在一个设计良好的系统中，易变性应该是层递减的。客户端是最易变的，Manager管理层根据用例而变化，Engine引擎比管理层稳定。引擎层变化必须是业务行为变了，比如支付行为了，这比Manager管理层的从先支付再增加积分这种组合的变化要更少一些。资源访问层的变化就更少了，增删改查这种原子操作不怎么变。资源层，理论上是要最少修改的。咱们经常提到的重构、重写，无论如何大改，也很少连数据库也一锅端了吧。 整体设计增量构建原则 这个原则无论什么领域和产业都适用。例如，你买了一块地打算盖个别墅。就算最好的架构师也不能一次性搞定整个设计，必须反复的和你讨论资金、使用人、风格、时间和风险。构建的时候也是先建设一层，再往上建。如果这时候用户想要加一层呢？这就看设计时地基等设施是否可以承载了。 命名 服务名和设计图一样，是与他人交流设计的一种方式。在业务层和数据访问层，描述性的命名方式非常重要。下面是推荐的习惯性命名方式： 1、服务名(为了好理解，服务名可以理解为类名)是至少两部分组成的复合词，采用帕斯卡命名法。 帕斯卡命名法指当变量名和函式名称是由二个或二个以上单词连结在一起，每个单词首字母大写。规则是单字之间不以空格断开或连接号（-）、底线（_）连结，第一个单词首字母采用大写字母；后续单词的首字母亦用大写字母，例如：FirstName、LastName。源自于Pascal语言的命名惯例，也有人称之为“大驼峰式命名法”（Upper Camel Case），为驼峰式大小写的子集。 2、服务名的后缀永远是服务的类型，例如：Manager、Engine、Access或者ResouceAccess. 3、服务名的前缀会根据服务类型而变化。比如Manager类型的，前缀往往是封装了易变的用例的名词；再比如Engine类型的，前缀往往是定义封装了什么事件的名词；ResourceAccess类型的，前缀往往说明了用例访问了什么数据资源。 4、只有在Engine类型的服务中，前缀才能用动名词。动名词就是ing形式的。如果把动名词用到了其他类型的服务中，很可能预示着这是按照功能分解的。 举个例子：在银行设计中，AccountManager(账户管理)和AccountAccess(账户访问)是可接受的命名，但是BillingManager(收单管理)和BillingAccess(收单访问)就有点功能分解的味道了。因为它传达了一种做什么而不是关于易变性的编排和访问的。CalculatingEngine是一个不错的选择，因为引擎做的一般都是聚合、校验、计算、转换、定位和搜索这些。 5、原子操作性的动词，比如Get、Put不应该用作服务前缀，应该用作数据访问层的接口名。 |
|
|
