1. 具有良好边界设计的类和组件，可以形成清晰的责任划分以及可控的依赖关系，困难之处往往在于细节之中，一旦疏忽，会对软件质量造成不良影响
2. 最简单的设计方式就是传统的水平分层架构，web代码一层，业务逻辑一层，持久化是一层，换句话说就是，相同类型的代码在一层。在最严格的分层架构中，每一层只能对相邻的下层有依赖关系。因为它不会过于复杂，所以在这种方式在项目的初期很合适。
3. 另一种组织代码的形式是按功能封装，即垂直切分，根据相关的功能、业务概念或者聚合根来切分。在常见的实例中，所有的类型都会放到一个相同的包中，以业务概念来命名。这种方式比较容易找到相关代码，毕竟是在一起，而不是分散在不同包中。
4. 通过采用『端口和适配器』『六边形架构』『边界、控制器』『实体』等，我们可以创造出一个业务领域代码与具体实现细节（数据库、框架等）隔离的架构。
5. 一个主要的规则：只有外部代码能依赖内部代码，反之则不能。即细节依赖核心，核心不能依赖细节。
6. 虽然这样写代码可以正常工作，但它可能不是按照合理的方式实现的。
7. 对于规范，核心问题是如何强制执行，很多团队多是采用『自律、评审』方式执行，我相信我的程序员，有这种自信当然好，但我们都知道，当预算缩减、工期临近的时候会发生什么。
8. 按组件封装，目标是将一个组粒度组件相关的所有类放入一个Java包中
9. 组件定义：在一个执行环境（应用程序）中的、一个干净、良好的接口背后的一系列相关功能的集合
10. 系统由一个或多个容器组成，容器由一个或多个组件组成，组件由一个或多个类组成
11. 在组件中，需要关注重点隔离原则，这是组件内部的问题，使用者不需要关心
12. public类型越少，潜在的依赖关系就越少
13. 强烈建议利用编译器来维护架构设计原理，而不要依赖个人自律和编译过程之后的工具
14. 我们的每一项设计决策都必须为未来的变化敞开大门。让我们现在编写的代码不对未来的代码产生阻碍时一项非常重要的技能，通常需要花费多年时间才能掌握。