DDD与Repository
Repository已经不是什么新鲜概念了。DDD模型自2004年提出，发展至今已经16年了。但是不少企业却无法实施，其原因也很简单：DDD是基于需求的，而很多并不理解需求；DDD是容易实现的，而很多设计者并不会编程。这种情况就有一些两头不讨好，而如果有办法结合统一的话，则会非常好用。
学习Repository的过程中，最先要进行的是思想的转变。在过往的编程过程中，大家往往将目光聚焦在CRUD中，导致每个程序员首先想的是我如何使用SQL实现我所要的目标。而在DDD过程中，实践者应当将目光聚焦中功能上，首先将需求分解为若干个功能，然后再将功能进行组合。
举例而言，某系统拥有组织机构和用户功能。组织机构树的每个部门下属若干个职位，每个职位都有用户担任，每个用户可以出任多个部门的多个职位。这时，系统设计师告诉你这里要有以下功能：
部门管理（部门的CRUD，部门下职位的CRUD，职位与部门的CRUD）
用户管理（用户的CRUD）
讲到这里，很容易看出，这里其实有四张表，也就是部门，职位，用户和用户职位关联表。表关系也容易理出，部门与职位1对多，职位与用户多对多。
如果你使用的是DAO思想（或者说分层思想），那么需求分析做到这一步也就结束了。你可以直接通过上述内容整理出你需要实现的接口，即每张表的CRUD。然后在前端实现一个界面，每个界面调用相关的接口程序也就写完了。比如，其中一个接口可能是这样的：
[Route(“~/api/SetPosition”)]
public void SetPosition(Guid userId, Guid positionId);
那么，现在问题来了。需求发生了一个变更，来了一个全新的需求，客户说我现在需求每个部门的更改必须通过流程进行。即当部门信息发生变更时，必须层层审核，最后才通过后，才能在更新数据。这个审核过程甚至包含了一部分关键职位的人员变化。
这时，那个坑人的系统设计师又站出来了，给了你一系列功能变化表：
部门修改申请（部门修改申请CRUD，部门申请审核，部门申请同步到部门表，部门申请同步到职位表）
看上去，这个设计很美好“自顶向下逐步细化”分解的也非常舒服。但是，你仔细研究一下就发现这里有两个巨大的坑：
1、新建部门修改申请。在部门修改申请时，试问是否要将以前的部门数据复制到这张申请表中？如果你不复制，那了不得了，全部门所有手动数据全部要用户自行输入此表，那恐怕最终用户会和你闹的不可开交——这什么垃圾软件？！而如果你打算实现他，那我告诉你，这张可怕的部门表里，字段不多，100个（呵呵）。
2、如果你说功能1其实是必须实现的新功能，和设计关系不大。那么你再观察，将部门申请同步到部门这个功能。他绝对可以细分为“修改部门”和“修改职位”两个子功能，而这两个子功能其实是之前的接口就实现的。那么，你是否为之前的接口留下了复用性？仔细看看之前接口的实现代码，你就会悲剧的发现，70%的可能性那个接口是无法复用的，因为查询代码其实不太一样。
那这只是我随手说的一个需求变更，如果有更多的需求变化呢？那么虽然代码还是能够复用一部分，设计空间释放也不会太麻烦。但是，仔细评判你的代码和设计，就会发现原来优雅而简洁的可复用设计的复用性越来越低，原来整齐而易读的代码的可读性越来越差。这就是人间悲剧。
而这时，Repository的思想从天而降，他也许能够为你可怜的代码带来一些让你惊喜的变更。如果使用DDD的思想设计上述内容，首先你需要确定领域。显而易见的，这里的领域可以这样划分：
用户领域：添加用户，删除用户，修改用户，修改用户的职位，移除用户的职位
部门领域：添加部门，删除部门，修改部门，查询部门下的职位，查询部门下的用户
职位领域：添加职位，修改职位，删除职位，查询职位下的用户，将用户添加到职位中，将用户从职位中移除
注：这里，如果是我写代码，我很可能会把“部门领域”和“职位领域”合并。这个并无不可，因为两者其实没有那么明显的边界。
在这个设计中，可以看到其实有些功能是重复的，比如说“修改用户的职位”和“将用户添加到职位中”。但是，在领域设计中，我却将其认为是两个不同的功能，因为他们的主体不一样。对前者而言，我先查出用户，函数的参数是“用户ID”和“职位名称”，这里使用出字符串的职位名称，即意味着对于用户领域来说，他不需要认识“职位”这个类。对于后者而言，我先查出职位，函数参数是“职位”和“一个或者多个用户ID”。这意味着，对于职位领域来说，他也不需要认识用户这个类。
这里可以看到，领域之间，耦合度很低。其实达到了最小知识原则所要求的内容。但是，实现过程中，可能会有这样的疑问，将职位添加到用户过程中，难道你不需要判断用户是否存在吗？当然，判断还是要判断的，但是我完全可以不认识用户这个类。通过将“用户职位关系表”中的“用户ID”字段与用户表中的“ID”字段做出外键关系，完全可以让数据帮我保证数据有效性。我只需要做一个简单的异常处理即可。
另外，耦合度低不等于不能耦合，在这里查询一次用户表，我认为也没有突破什么界限，所以完全没有问题。
在设计完领域后，需要再设计边界，也就是说由哪些类将这些功能全部暴露给外界。这时可以这么设计：
部门类：添加职位，修改职位，删除职位，查询职位下的用户，将用户添加到职位中，将用户从职位中移除
用户类：查询我所在的部门和职位
用户服务类：用户的CRUD
部门服务类：部门的CRUD
这里，实际是将部门当作了职位的聚合。这只是我随手写的设计，没有实践过也不知道有没有什么问题。但我想大致应当是正确的。这时，我就将所有功能都通过这几个类暴露在外界。在考虑这些内容的情况下，再来上述需求时，问题就明确了，他需要新建一个领域：部门修改申请。
部门修改申请：通过部门新建修改申请，通过旧的修改申请新建修改申请，审核修改申请，将修改申请同步到部门中，将修改申请同步到职位中。
现在再来看之前的两个大坑。问题1其实是规避不了。因为这个就是新功能，规避的唯一办法就是加钱，钱到位了功能也就到位了。而问题2确实就简单了，因为你可以直接调用暴露在“修改职位功能”将申请表中的用户给到对应职位，也可以通过调用“修改部门功能”直接将部门信息反向同步，而不需要考虑代码是否优雅，因为这里就是调用一个函数，并不存在优雅与否的问题。
再到以后，如果再有新功能，哪怕你还是需要释放设计空间。但你在重构的时候，已经整理过的功能就不需要整理第二遍。你只需要交被释放出的设计空间全部放回领域中，重构的工作量大大减少。而这，就是我所看重的DDD的核心优势。
针对到实现层面，之前那些乱七八糟的领域功能，其实就是Repository，他的出现自然而又简单。你所需要的只是简单的变化一下自己的思想，多写几十行代码，仅此而已。
最后，稍稍总结一下。完成以上内容的核心和关键其实并不是你对DDD了解多少。而真正有效的是你对需求了解多少，你认为需求有多少内容可能发生变化。对需求把握才是软件设计的核心。任何设计思想，设计模式都基于对需求的理解。我个人对软件思想的重要理解：
不基于需求任何想法都空谈，不理解需求任何代码都是胡说，不把握变化任何设计都是假想。
与君共勉。
