领域驱动设计笔记（一：关于登陆的思考）
领域驱动设计笔记（一：关于登陆的思考）
参考文章
代码精进之路：从码农到工匠 作者 张剑飞
怎么才能保证建模的正确性？
这个问题确实值得思考，但是作为接受辩证论教育的我们，应该知道，没有绝对正确的事，立场角度不同，评判的结果也就不同。那么有没有什么是可以暂时不变的？先想一下我们做项目的首要目的是什么？
项目开发的主要目的
笔者认为，项目的主要目的是为了完成需求。不管是个人项目，还是企业级的项目，一开始的首要目的就是功能（需求）的实现，其余的一些问题，比如并发、调优、中间件的应用，都是我们在实现了基础需求后，需要应对的问题（当然这里不是说做基础需求的时候就不该考虑这些问题）。而这个问题不是确定的，因为客户可能要求你做分布式，做高并发，但实际情况并不会出现如此大的访问量，这只是一点。重要的是另一点，也就是你的项目即使没有用到各种中间件，各种算法，其实本身的项目也是可以运行的，只要项目能够走通完整的流程不出错，可以正常运行，那就是一个完整的系统。
完整该如何定义？
那什么叫做完整呢？完整该如何定义呢？用一个最简单的例子来思考，用户登陆。
用户输入用户名，输入密码，后台做校验，成功或失败。
这样的登陆叫做完整吗？从代码和业务两个层面分析。
-
在代码层面，我认为已经完整了，登陆这个功能已经做完了。再多下去，也只是扩展，增加一些token颁发，验证码校验，密码加密解密等等，不影响完整性。
-
在业务层面，我认为不完整。登陆功能，为什么会存在呢？
是为了校验用户是否是该系统的用户，保证安全性，或通过注册增加产品的用户量。
那校验是业务的主要关注点吗？
不是，校验只是一个过程，在业务层面，主要关注的是结果。比如分布式的引入，只是我的需求是要满足一定的并发量，为了实现这个目标，在代码中使用了分布式系统，如果有别的技术可以同样实现高并发访问，那我也可以使用，我关心的只是系统能不能够承载这么大的用户量，至于怎么实现，那是开发的问题。
对于登陆这个功能，我们其实只关心，这个用户是登陆成功了，还是登陆失败了。
笔者认为，完整的概念应该是代码完整性加业务完整性。 这里的代码完整性说的很肤浅，只是为了抛出概念。
对于代码，我要知道你输入了什么，输入的是否正确，我需要给你赋予什么权限，又或者进行一些其他的操作。
对于业务，关注点可以更细一点，在登陆失败时，作为一个用户，我需要知道，我为什么登陆失败了，是我没有注册？还是我的输入有问题？还是你的系统出现了问题？在登陆成功时，对于需求，可能我需要知道用户是不是第一次登陆，如果是第一次登陆，那我可能会给他发一些优惠券，或者发送一些友好信息。
在考虑业务的时候，应该把自己当成一个普通的用户，你并不知道里面是如何实现的，这样会更容易抓住本质。
对于登陆，小系统的细节可能没有那么多。当再复杂一点的时候，无头绪的思考并不是一个有效的方法。那么，有没有什么方法能帮助我们建立完整的模型呢？见下一章。
此章总结
本章主要是引导代码思维到业务思维的转变，代码是为了满足业务需求而存在的，没有人使用的代码，能说他是好代码吗？不站在使用者的角度去思考代码如何编写，那代码注定只是代码，不会成为产品。业务与代码没有高低之分，是相辅相成的，你中有我，我中有你，代码组成业务，业务也驱动代码。