【s 进程的领导者（在它之下有子进程）】；
不能这样理解，APUE上翻译为会话首进程（session leader），这相对作业控制中的会话来说的。创建会话的进程才能叫leader进程。
leader进程可以接收控制终端或伪终端发送SIGHUB信号，如果它自己死了（可能是运行完毕或出错退出）。会给同一session下的所有进程发送SIGHUB信号。
会话下有进程组，一个会话一般会有多个进程组，一般由管道操作产生。
一个进程组下，可能有一个或多个进程，一个会话下可能也只有一个进程组一个进程。（极端情况，可以自己写程序验证，已有的应用程序我没发现有这种极端情况存在）
linux查看进程状态命令ps的详解名称：ps使用权限：所有使用者使用方式：ps [options] [--help]说明：显示瞬间行程 (process) 的动态参数：ps的参数非常多, 在此仅列出几个常用的...
上个月初或中旬，看过DDD简化版（不记得是英文版还是翻译版），还专门找过一些DDD战术实现相关文章看过，当时也懵懵懂懂。而这段时间，刚好拿着C++的基础在看，悟出点东西来。DDD的设计理念相当正确。阅览过的C++写的类，认真考虑不就是DDD倡导的设计方法吗？当然想通这还不行。如果遵循DDD设计规范能带来什么好处才是重要的。首先DDD揭示了面向对象设计的本质。其次、为设计模式使用创造条件，使用设计模式，代表编写的代码向标准化迈进。再次、标准化的业务模型价值，搞企业开发的同学应该能体会。
而现在的框架，典型代表：spring、hibernate大力宣扬他们pojo思想。造就大量的controller+service+dao模板代码。这些代码的通用、复用、可维护性、扩展性人为被弱化。这种设计通常情况下是最糟糕的设计。（当然一些小功能，用这种理念写，问题不大）。所以个人认为，DDD应该被推广。但是DDD推崇的交流、设计方式需要变通一下，完全遵循项目整体效率不高。
浅析DDD(领域驱动设计)最近在做一些微服务相关的设计，内容包括服务的划分，Restful API的设计等。其中比较棘手的就是Service的职责划分：如何抽象具有统一业务范畴的Model，使其模块化...
这种模式，基本是国内开发采用的主流模式。我待的团队，也是类似模式。
最近我看了一下领域驱动设计，领域启动设计，比如交流就是低效的问题。但是它提出的专业术语定义，比较好，我曾经带领过的团队，就因为术语不统一。后期交流，理解造成很大麻烦。敏捷开发模式与领域驱动设计开发模式是互相矛盾，单需要折中处理，好的留下来。
浅谈敏捷开发章节 什么是敏捷开发（What） 为什么使用敏捷开发 （Why） 如何使用敏捷开发 （How） 采用敏捷开发的产品开发效果 1.什么是敏捷开发（What） 1.1 敏捷开发是...
