※ 引述《DongFeng ()》之铭言：
:
: 目前手上的 Project 使用 Laravel Framework 开发, 程式码架构依目录区分为 Controller(Presentation)->Service(Business)->Repository(Data)->Entity
:
: 基本上各层的存取范围以箭头方向为准且不可逆, 但因为协同开发的关系偶尔还是会出现 Controller直接存取Repository的情况
:
有兴趣可以参考 Uncle Bob 的 Clean Architecture，YouTube 上有演讲录影，
也有出书，网络上也可以找到实际的程式码。但因为是概念性的东西，每个人的
理解和实作都有些不同。
我觉得他有一个好处，是可以跳脱 Framework 的思维，单纯回归到最原始的 OOD
的概念。这也是为什么每个语言 / Framework 都可以实作 Clean Artitecture，
但每个人做得出来的东西又都长得不太一样的原因。
:
:
: 因为没有新的 feature/issue 的关系, 所以本周有空档可以回头整理之前写的程式码
:
: 越整理我就越沮丧
:
: 我发现自己没有分辨哪些逻辑该归类到哪一层的能力, 举例来说:
:
说真的，我自己是觉得很多时候都是 trade-off，但如果真的很在意，其实这个
架构提供了一个满不错的指引，但即使有这份指引，还是要考量很多东西。没有
最好的架构，只有最适合当下情境的架构。
这篇文章我会试着以我的思路，提出一些问题，再提供一些假想的情境，然后说
明如果是我，我会怎么安排。
Clean Architecture 把系统画分成以下几个组件，而且各自的职责非常清楚：
1. 与核心业务逻辑相关的，抽象的组件，这些组件不应该知道任何的实作细
节，例如数据库，Controller 等等。
- Entity
- UseCase 物件
2. 让实作细节与核心业务逻辑沟通用的接口，通常又分两类：
- 从某处拉资料，例如 Repository 接口
- 把资料送到某处，例如 Presenter 转换成让 Controller 往外吐的 JSON
3. 实作上述接口的类别，也就是实作细节
: