简介
多个范畴的生命周期
人一生的生命周期被各种不同的场景、任务、角色、身份切分成了各不相同的生命周期，其中有核心生命周期，有非核心生命周期，有些必须自己做(读书、生活、谈恋爱)，有些可以交给别人做。
在人类历史中，随着工作越来越复杂、工作任务越来越多，人类协作越来越精细，然后就产生了分工，分工就是人类因为协作产生的生命周期的切分。
明确了生命周期这个概念就会意识到，随着事物的发展，把它的一部分职能从其核心生命周期切分出去，构造出新的生命周期，能够帮助这一事物明确自身的核心生命周期、明确自己的职责和权力，有更多时间用在自己擅长的事情上。
代码、技术、业务和管理
要分得清楚访问代码、业务代码、存储代码、胶水代码各自应在哪些层级，它们应该是什么角色，而不是所有代码散乱的混在一起，看起来似乎按照经典的MVC分层，实际上业务代码却同时出现在controller/service/dao，这样其实并没有明确的划分。
正确的做法应该是controller完成访问逻辑；DAO完成存储逻辑；service完成胶水逻辑，承上启下，利用DTO转换访问参数、执行业务逻辑、调用DAO映射存储模型、再利用DTO把业务处理结果转换为响应结果，业务逻辑在业务模型中实现。如果把业务逻辑跟业务数据在一起实现就是充血模型，进一步深化就是DDD模式。
如果把业务逻辑跟业务数据在一起实现就是充血模型，进一步深化就是DDD模式。只有这样才完成了明确的软件层次划分，每层各司其职、权责对等，否则就是大泥球。 明白了这一点，自然就能分得清楚业务的事务跟关系数据库的事务不是一回事，也就不会考虑完成业务上的事务要依赖关系数据库事务确保数据完整性。
完全可以把二者分开，利用更符合业务规律的做法去实现，甚至业务本身已经有成熟的方案确保数据完整性，而不再需要依赖关系数据库事务。在业务上对关系数据库事务ACID特性的依赖既然不再是必须，对拥有ACID特性的数据库依赖自然也就不再是必须，完全可以根据业务需要选择合适的存储方案。
业务模型和具体实现不再依赖于某些具体方案的技术特性，实现了业务与技术的解耦，也就更容易实现横向扩展。现在又发现横向扩展也是自然界的一个基本特性。无数基本粒子构成原子、无数原子构成一个具体的宏观物体，一个人不够用就增加更多人。如果一个系统的规模在横向扩展上达到了瓶颈，不能再靠简单的增加数量获得提升的时候，一定是这个系统的组织架构存在某些不合理因素。
说到这里自然就要说到业务和技术的关系。前面说到软件是现实世界的映射抽象，由虚拟人代替自然人去完成一些工作。要做好软件自然就要理解业务，对业务的理解越深刻就越有可能做出优秀的软件。
但是现实世界太复杂了，随着业务发展，软件规模会越来越大，复杂性越来越高，一个人难以胜任全部架构工作，于是就产生了架构师团队，架构师也有了更细致的分工。架构师的生命周期也相应发生了拆分，也就产生了业务架构、应用架构、系统架构。
架构师为了能够实现自己的架构思想，自然需要与职能对等的权力。所以架构师其实不是一个纯粹的技术职位，而是拥有管理职能的职位，而不同角色的架构师对技术的要求也不尽相同。