|
|
一、数据库只是实现细节从系统架构的角度来看，数据库并不重要 —— 它只是一个实现细节。如果就数据库与整个系统架构的关系打个比方，它们之间就好比门把手和整个房屋架构的关系。 二、Web 是实现细节GUI 只是一个实现细节，而 Web 则是 GUI 的一种。 三、应用程序框架是实现细节请不要嫁给框架。 我们可以使用框架 —— 但要时刻警惕，别被它拖住。我们应该将框架作为架构最外圈的一个实现细节来使用，不要让它进入内圈。 如果框架要求我们根据它们的基类来创建派生类，就不要这么做。我们可以创建一些代理类，同时把这些代理类当作业务逻辑的插件来管理。 另外，不要让框架污染我们的核心代码，应该依据依赖关系原则，将它们当作核心代码的插件来管理。 以 Spring 为例，千万别在业务对象里到处写 @Autowired 注释。业务对象应该对 Spring 完全不知情才对。 四、拾遗1、按层封装最简单的设计方式，就是传统的水平分层架构，这通常被称为“按层封装”。 这种常见的分层架构中，Web 代码分为一层，业务逻辑分为一层，持久化是另外一层。换句话说，我们对代码进行了水平分层，相同类型的代码在一层。在“严格的分层架构”中，每一层只能对相邻的下层有依赖关系。 2、按功能封装另一种组织代码的形式就是“按功能封装”，即垂直切分，根据相关功能、业务概念或聚合根来切分。 这种方式，类和接口与之前相比类似，但是相比之前，这次它们都被放倒了同一个 Java 包中。相比“按层封装”，这只是一个小变化，但是现在顶层代码结构至少与业务领域有点相关了。 3、接口和适配器如果 Bob 大叔所说，通过采用“端口和适配器”、”六边形架构“、”边界、控制器、实体“等，我们可以创造出一个业务领域代码与具体实现细节隔离的架构。 内部区域包括了所有的领域概念，而外部区域则包含了与外界交互的部分。这里主要规则是，只有外部代码能依赖内部代码，反之则不能。 4、按组件封装分层架构设计的目的是将功能相似的代码进行分组。从实现角度将，层就是代表了 Java 包。在严格分层的架构中，依赖指向的箭头应该永远向下，每一层只能依赖相邻的下一层。 ”按组件封装“的做法，将”业务逻辑“与”持久化代码“合并在一起，称为”组件“，目标是将一个粗粒度组件相关的所有类放入一个 Java 包中。 5、组织形式与封装的区别我们将 Java 程序中的所有类型都设置为 public，那么包就仅仅是一种组织形式了，而不是一种封装方法。最终，如果忽视包的概念，那么想要采用的任何架构风格就都不重要了。
转载请并标注: “本文转载自 linkedkeeper.com (文／张松然)” ©著作权归作者所有 |
