组织结构的领域建模 (1): 公司、部门、岗位与员工
在本章中，我们将迎来第一个版本的组织结构领域模型。这是大多数人一开始确立的领域模型，可惜往往也是他们采用的最终模型。这个模型简单、直接，但却存在着致命的缺陷。
假设我们为一家公司的组织结构建模，显而易见的领域对象有：
- 公司（Company）。公司是在工商和税务部门登记建立的一个实体。公司的主要标识是它的名字，除此之外往往还有工商执照号码、开户银行、注册地址等等公司特定的属性。而且，不同国家的公司往往有不同的属性集。
- 部门（Department）。在公司之下可以设置多个部门，例如财务部、工程部、开发部，等等。与公司不同，部门的设立不需要在国家机关进行登记，可以在公司内部自由设置。若有必要，部门可以划分为若干层级，例如人力资源部下面可以划分为薪酬福利科、培训发展科、人事科等等。
- 岗位（Post或Position）。在每个部门下可以设立若干岗位，例如经理、主管、招聘专员等等。公司之下也可以直接设置岗位，例如总经理、副总经理、总经理助理等等岗位，不属于任何一个部门，而是直接设置在公司之下。
- 员工（Employee）。每个岗位由一个或多个员工充任。例如财务部经理由一个员工担任，招聘专员由三位员工担任。有时候，一个员工也可能担任多个岗位，例如张三担任总公司的技术总监，同时兼任广州分公司的总经理。
公司之下可以设立多个部门，也可以设置若干分、子公司；部门之下可以设置若干个下级部门。
根据上面的描述，我们可以用UML的类图来表达这个领域模型：
这个模型非常直观，真实地反映了现实领域。但是这个模型存在严重的缺陷：
- 只适用于企业类型的组织，而不适用于学校、党政机关、军队等其他类型的组织。
- 无法直接推定岗位所从属的实体，是哪个部门还是哪个公司。
- 组织实体（公司、部门）间的层级，不能以简单、直接的方式呈现和处理。
现实中，为了解决第二个问题，往往采用下面两种方法之一：
- 在公司下设立一个虚拟的部门，叫做“本部”或别的什么名称，然后将总经理、副总经理等公司级岗位转移到这个部门下。类似的做法是，每个公司通常都有一个叫做“办公室”或“总裁办”的部门，可以将上述公司级岗位移入这一部门，作为该部门下的岗位。两种做法的共同之处是：经过这样的改造，岗位都是挂在部门下的，不再在公司下挂岗位，模型得到了简化。
- 在岗位类上同时定义两个多对一关联属性，一个指向公司类，另一个指向部门类。同时另外添加一个属性，用于鉴别该岗位属于公司还是部门。如果鉴别属性的值是“公司”，那么“公司”属性值不为空，而“部门”属性值为空，代表该岗位属于某个公司。如果鉴别属性的值是“部门”，那么“公司”属性值为空，而“部门”属性值不为空，代表该岗位属于某个部门。
两种做法都有根本性的缺陷。
第一种做法的根本问题是它扭曲了模型，用技术上的方便性扭曲了业务上的正确性。总经理、副总经理等岗位本来是公司的负责岗位，现在却变成了部门下的二级岗位，与其他部门的主管岗位（例如财务部经理）同级。系统还必须针对虚拟部门（上面例子中的“本部”）或特殊部门（上面例子中的“办公室”或“总裁办”）做特殊处理（例如其他部门可以裁撤，虚拟部门不允许裁撤；又例如分配部门职责时要跳过虚拟部门；又例如流程审批要总经理审批时必须到办公室这个部门去寻找总经理岗位，等等等等）。为了技术上的方便性扭曲领域模型的正确性是绝对不可以接受的做法。
第二种做法稍微好一点，但仍然对现实做了一定程度的扭曲。一个岗位只能属于一个部门或一个公司，二者是互斥的；但是在岗位这个领域类上却同时定义了“所属部门”和“所属公司”两个属性，只是通过很不直观的代码实现了“二者选一”的语义。
当将领域模型应用在非企业组织——例如大学，它的组织层级是大学-学院-系-专业——时，第二种做法的问题进一步突显。这时岗位不再是在公司或部门下设立，而是在学校、学院、系、专业下设立。这样一来，我们的岗位领域类必须做一个彻底的修改，要取消对公司和部门的关联，建立对学校、学院、系和专业的多对一关联。
我们需要一个更完善的模型，能够：
- 直观、正确地反映现实世界
- 支持各种类型的组织，而不只是企业型组织。
在下一个模型中，我们将解决这些问题。