Swarb的博客：低头做事，抬头做人

微服务、架构

2. 单一职责原则： * 应该有且仅有一个原因引起类的变更 * 由来：假如有类Class1完成职责T1，T2，当职责T1或T2有变更需要修改时，有可能影响到该类的另外一个职责正常工作。 * 解决： 2)里氏替换原则：继承必须确保父类所拥有的性质在子类中仍然成立。 * 由来：只要父类能出现的地方子类就能出现。反之，父类则未必能胜任。 * 增强程序的健壮性，即使增加了子类，原有的子类还可以继续运行。 3)依赖倒转原则： * 高层模块不应该依赖底层...

中小型研发团队很多，而社区在中小型研发团队架构实践方面的探讨却很少。中小型研发团队特别是 50 至 200 人的研发团队，在早期的业务探索阶段，更多关注业务逻辑，快速迭代以验证商业模式，很少去关注技术架构。这时如果继续按照原有的架构及研发模式，会出现大量的问题，再也无法玩下去了。能不能有一套可直接落地、基于开源、成本低，可快速搭建的中间件及架构升级方案呢？我是一个有十多年经验的 IT 老兵，曾主导...

一般我们都采用分层架构，先思考业务，要解决什么样的业务问题，再去思考技术实现。l  正向思维：界面(UI)—>业务逻辑（BLL）—>数据逻辑（DAL）—>数据实体（Model）—>数据存储（Db）l  反向思维：数据存储（Db）—>数据实体（Model）—>数据逻辑（DAL）—>业务逻辑（BLL）—>界面(UI)。从数据库推导到界面，从界面推导到数据库。搞清楚类之间的关系。

http://www.woxihuan.com/46528208/1323334777088641.shtml

http://www.cnblogs.com/EmptyFS/p/3621484.html

http://bbs.csdn.net/topics/380092212 http://www.codeproject.com/Articles/14058/Parsing-the-IL-of-a-Method-Body