感觉自己的架构水平好弱，请问有没有推荐的最佳实践教材？

php 不就应该是面条嘛,还能咋地.......

别整这么多没用的

要想去搞什么优雅啊 耦合度啊 那你得放弃世界上最好的语言，转而去研究世界上最具有模式的语言： java
你觉得这个代价值得吗。

尝试下 Laravel 框架，看看源码

@uxstone 面条是啥意思？
@mikulch 你的意思是写 PHP 只要无脑面向过程就行了、完全没必要追求优雅吗？
@klom303 看过不少框架源码，学到一些模式，但不知该如何合理运用在自己的实际项目中……

@mikulch Java=世界上最嗦的语言。

JAVA 跟优雅没有任何关系，就是结构工整、语法嗦，追求优雅的话你可以看看 laravel ，关键字 repository ，推荐你看看这个 http://oomusou.io/laravel/laravel-architecture/

少年听过 DDD 吗

@peinhu 谢谢。感觉 Laravel 都快成为优雅的代名词了。不过前阵子鸟哥才说过某优雅的框架执行速度不行啊……
@mercurylanded 搜了一下，看不太懂，有入门级的教程吗？

@mokeyjay http://item.jd.com/11961038.html

学架构没什么好教材，最好的办法就是工作中努力把事情做得更好，更接近完美。

@vagasnail 感觉嗦+10086

一年多谈啥架构，也没什么教材，架构本身就是掉坑掉得体无完肤总结出来的东西

@mercurylanded 感谢，有实际案例就会好懂一些
@ElmerZhang 说的倒是容易……我也想“努力把事情做得更好，更接近完美”，但并不清楚该怎么做，也不知道这么做到底对不对

优雅 -> scala
结构 -> java

Laravel 性能还好的，用 https://github.com/denghongcai/laravoole 免去框架加载时间

@vagasnail @Troevil 然而 Java 是典型的工业界语言， verbose yet obvious (Scala Cookbook 里的原话哇咔咔)

程序设计是从需求分析阶段就开始了...不过现在干 php 的都挺不重视这个的

设计类最主要的还是需要学习面向对象设计方法论，经典的比如 grasp 的创建者模式和信息专家模式在划分类时都是很有用的指导。这方面可以看看 uml 与模式应用 这本书

进一步地，可以看看领域驱动设计，尽管可能受限于环境因素不能照搬，但理解它的领域模型聚合实体值对象领域服务领域事件等概念还是挺有用的。这方面的书写得都挺难看的...随便找本书翻翻了解下概念，然后可以去汤老师 cnblogs.com/netfocus 的博客上看看，他的文章写得很好

最后，我的感觉，不一定对， php 这行业平均水平就这样了，写写过程式代码完成需求就行了，你弄些复杂的概念进来同事不一定看得懂，还影响同事间关系...业务代码翻来覆去就那样，平时工作里干的那些零零碎碎的工作对自己的技术提升真是有限，有时间多学点基础知识，搞点完整的复杂项目，这种提升才是真实的

建议看看“企业应用架构模式”。架构模式很大程度上跟语言无关
https://book.douban.com/subject/1230559/

去大公司做大项目

才工作一年，别想太多了，多干活多写代码，等你感觉代码哪里不爽了，或者哪里重复工作多了，再去看一些架构的书籍，就水到渠成了

写 PHP 不就是图快吗，还要啥自行车

同推荐 企业应用架构模式， 以及其作者 Martin Fowler 的博客

一年。。 PHP 。。。谈架构。。

语言只是工具，架构方案与语言关系不是特别大。现在 PHP 中的 ZF ， Symfony 框架，甚至 PSR （命名都是 Copy JSR ）都是从 Java 中获得灵感。

不要为了什么追求架构，模式，想尽办法去看书，去套用。哲学上这叫形而上学，大部分情况下把简单的事情搞复杂。

多写写代码，多进行实践，回过头来再去看看那些架构和模式，比较一下自己之前的方法，或许有顿悟的感觉，以后再应用就轻松得多。

Unix 编程艺术

《重构》。

一直以为 php 和 jsp 一样，怎么快怎么来

github 是最好的学习材料 多看看别人的 code
但也不要太过于追求架构，如果跟同事一起开发，同事为了改代码，打开 7 ， 8 个文件才找到真正实现的地方，估计心理要骂娘了。

《架构即未来》

同 lz 差不多情况， 不过现在看框架的 源码，收获很大啊。

一年。。。

一年，还是做 php 的，谈啥架构？

能快速出活就 OK 了，要啥自行车？

@peinhu 太偏颇了吧

@misaka19000
@jwdstefanie
@zuston
不好意思，我虽然是个普通的 PHPer ，但还是比你们有点志向的

这种事情，真的需要场景和老师，比较经验向我觉得。多看看别人的源码吧。

架构这个东西不是刻意就能学来的，工作中项目中可以多思考，而不仅仅是完成任务就行了。

架构？还是结构？

我猜楼主想问的是『怎么在代码里把类组织好』。

除了多写，额，多写也没用，得看写什么东西。

多造轮子，从零早起，慢慢就有感觉了。

@mokeyjay 写 php 几年，现在也写 python,java,scala ，何来比我有志向,哪看出来的？ laravel 的架构同时也是模式复用的结果， java 也有，语言之争也没啥意思。我是没看懂你 @我干嘛？

架构和语言无关
架构是一步一步演进出来的

加油吧，先从重构做起，先把代码做到可测试化

架构要结合业务吧，适合业务场景的架构才是好的

架构就是你写代码的经验啊。 这东西是随着你开发经验来完善的。即使你看完了世界名师的架构框架，你没有从实践中总结出经验，你写出来的代码和现在的水平是相差无几的。

你指的是代码层级的设计，这个和我们常规意义上说的架构联系不大。单说代码层级的设计的话，多写多修改，有经验了深刻理解下设计模式、重构，再反过来指导改进代码。再就是多看别人写的好代码，依葫芦画瓢。数据库的设计先读一本经典的教材，从了解范式入手。

进入实践-读书-反馈到实践中的优化循环就上路了。

书就先不推荐了，你应该已经有了比较多的代码实践，可以先了解常见的设计模式，然后读一个 mvc 、依赖注入类框架的源码。 PHP 系的可以看看 laravel 的源码。

然后就是一些依靠自己平时多关注的最佳实践的积累了，比如看了 laravel model 的设计后你就会发现，一个关系型数据库表在设计字段的时候通常会加入 id 、 createdAt 、 updatedAt 、 deletedAt 等必要字段，然后自己思考后考虑到数据会存在类型、状态，所以每个表还会添加 type 、 status 字段。后来你又看到互联网 web 领域的后端应用一般要求最终一致性并注重低延时，所以你就取消了外键字段，用单独的 id 字段来记录记录之间的关系。

没有多大诀窍，花时间去积累去关注。

@Troevil +1

@uxstone +1

@winiex 问个问题哈，我还没到架构这个层面，咳咳 取消外键字段的话，那么数据一致性靠代码来保证么，咳咳咳，而且外键依赖不是只影响写入效率么，不影响读吧

“看需求”

不要为了应用某种设计模式而强行编码，有时候面条代码（面向过程）反而是更合适的实现方式。
每一种开发理念都有其合适的应用场景的。
（ JAVA 嗦，但是在合理设计文档充分的前提下， JAVA 很适合开发健壮性足够高的业务代码。）

我就给你一个意见：你不要只看 PHP 好吗？

从最近看 C#的 Orchard2 得到的经验是，多看优质的代码，受益匪浅

架构这个东西和设计模式一样，属于一套形而上的东西，更像是先人把自己的经验进行总结后的产出。所以最好的方式毋庸置疑是看源码

看框架源码

个人感觉不用刻意追求这些东西:
1. 平时多看好的项目的代码, 感觉到了自然就到了
2. 可以追求好的架构, 可能会得不偿失
3. 有时候是真没时间搞什么好架构

@a15819620038 对对，我确实是想问“怎么在代码里把类组织好”以及“如何设计数据表”
@zuston 额不好意思我点错了
@huijiewei 请问“可测试化”是指单元测试吗？
@winiex 感谢耐心回答，这么多人都推荐 Laravel ，我一定要去看看

真考虑框架的速度，还不如自己写最基本的 mvc 比 85%的框架速度都快

来呀，一起写 Java 呀。[滑稽]

@mokeyjay PHP 我也写过，写完之后发现这货真的是天生就是为 Web 而生的，而且 PHP 的优势就是快，写起来简单，架构能力这种反而是 PHP 的短板，放着 PHP 的长处不用为什么非要去发扬它的短处呢

如果非要谈这些架构，为什么不用 Java ， Python 这种语言呢

想要入门架构设计，推荐你读读软件架构设计，当然，如果你想要的其实是实现整洁优雅，你可能需要的是 effective 系列而不是学架构设计

@mokeyjay 如何设计数据表这是需要经验和结合业务来谈的，如果你想要避免设计出反人类的表，你可以读读 SQL 反模式这本书，还是有点用的，至于如何设计出最适合业务的，这个一般没有书讲，只能你自己去深入了解业务，或许可以查查领域模型设计相关的资料。

@BigDipper7 一致性是分几个级别的，一般来说，除了类似于支付宝设计资金流转这样的一致性极敏感业务， web 后端的一致性要求都不高，在 CAP[1] 中 Web 后端应用舍弃了 C ，而强调 A 、 P 。

至于不用外键，这个原因很多，你可从 Web 后端应用的特点与外键的优劣来理解，可以参考这个[2]。举个例子， Web 后端的业务决定了删除数据记录以置脏位为实现，外键也受到了类似的限制。带外键的表写入效率低下是主要原因之一，外键不能支持后端数据库服务水平扩展（简单描述的话就是加机器）也是一个重要原因。

[1] http://julianbrowne.com/article/viewer/brewers-cap-theorem
[2] http://stackoverflow.com/questions/83147/whats-wrong-with-foreign-keys

@winiex 谢谢大佬，嘎嘎，从来没想过这个，涨姿势了

@denghongcai 抓了个现行 /滑稽

@garveen 略有点尴尬，把 fork 版本发出来了 https://github.com/garveen/laravoole