面向过程和面向对象
前几天在群里和小伙伴们讨论OOA。
有人问：“这是什么？”
答：“面向对象的分析，是一种需求分析方法。”
回：“没听过。”
后来我想了一下，可能是刚接触IT行业就赶上了java的盛行，没听过也很正常。
记得我上大学的时候，主流还大都是C、VB之类的。
后来竟然发现自己没有办法很好的去解释“面向对象”和“现象过程”的区别。
于是请教了度娘，看到了一个用“五子棋”为例的解释，非常清晰。
例如五子棋，面向过程的设计思路就是首先分析问题的步骤：1、开始游戏，2、黑子先走，3、绘制画面，4、判断输赢，5、轮到白子，6、绘制画面，7、判断输赢，8、返回步骤2，9、输出最后结果。把上面每个步骤用分别的函数来实现，问题就解决了。
而面向对象的设计则是从另外的思路来解决问题。整个五子棋可以分为 1、黑白双方，这两方的行为是一模一样的，2、棋盘系统，负责绘制画面，3、规则系统，负责判定诸如犯规、输赢等。第一类对象（玩家对象）负责接受用户输入，并告知第二类对象（棋盘对象）棋子布局的变化，棋盘对象接收到了棋子的i变化就要负责在屏幕上面显示出这种变化，同时利用第三类对象（规则系统）来对棋局进行判定。
所以，面向对象的方法讲究的是抽象、对象化。
对于简单的业务需求，使用哪种方法的差别其实并不大。
但是如果业务需求比较复杂，以后希望有较好的可扩展性，“面向对象”会更加适合。
而现实是，我们面对的基本上都么啥简单的业务需求。
并且因为未来的不确定性非常大，变化又多又快，现在OO的方法就更加适用了。
作为DEV，会使用OO进行设计和开发。
而作为BA，会使用OO进行分析，简写也就是OOA。
那么我们如何使用OOA呢？
我们会使用UML这类工具去进行分析，思考，也就基本是在使用OOA了。
关于UML之前说的也比较多，而且市面上的书籍非常多。
感兴趣的可以自行研究下。
今天想分享的是我最近在研究的另外一种分析方法DDD。
DDD与UML
因为DDD和UML都是OO的，所以如果你对UML比较熟悉，那么理解起来DDD不是那么的困难。
如果你以前写过代码，那么理解起来会更加容易。
通常我们会用UML进行业务描述，甚至是对象关系的描述。
但是，代码是如何实现的，如果我们的活动图的某个活动扩展或者改变了，会对数据库或者代码产生多大的影响，这些都无从得知。
换句话说，我们的UML模型和代码实现是脱离的。
不错，我们用UML描述了我们产品的业务过程，对象生命周期，对象关系。
但是这些真的只是我们的描述而已。
最近小婧的产品遇到一件比较棘手的事情。
我们的标准化产品给到客户去实施，难免会需要根据客户的业务需求进行二次开发。
基于产品保护的原则，底层代码是不能提供给实施团队进行修改的。
按照道理来说，实施团队只能在我们提供的开放接口以及业务层进行二次开发。
虽然我们也是用OO的方法分析、设计和开发的产品，但是在面临这样的要求是显得很被动。
这里面的原因有很多，但是根本原因是在分析和设计的时候，并没有把领域层、应用层分离开。
我们把很多的业务规则写在了应用层，导致修改的时候需要动到一些基础的业务规则。
我们开始研究DDD，发现其实DDD会更适合我们这类大型复杂的产品。
首先，DDD的分层结构让设计更加清晰。
其次，DDD的聚合设计会让我们对对象之间的关系更清晰。
我之前专门写过一个需求是关于“删除依赖性检查”的。
比如，一个人的性别下拉选项中有：男、女、未知。
这个下拉选项的三个值是允许用户配置的。
此时，用户在【设置】中删除了“未知”这个值。
那么原先选择了“未知”的人，在性别一栏中应该显示什么呢？
一般情况下，有这样几种处理方式：
a. 删除“未知”时检查，如果被使用，提示用户不能删除。——我的需求就这么提的。
b. 在保存性别信息时就直接copy，而不是引用“ID”的方式。
然并卵，很多时候大家都不清楚到底有多少地方引用了“未知”。
而DDD的聚合根可以很好的解决这个问题。
另外，DDD的思路更加适合实现高内聚低耦合。
DDD提倡将一个对象抽象到独立的程度，并且对于会被复用的对象作为Value Object的方式。
这样在分析的时候不至于搅成一团乱麻，我们分析的过程也会更加顺畅。
需要重建的思维框架
那么使用DDD后，就不使用UML了吗？
和团队的成员讨论后，大家觉得这样的处理方式会更加合适。
作为BA还是需要通过之前的OOA方法，使用UML的思路进行需求的分析。
这个原因主要在于两点：
客户很多时候说不清楚自己到底问题是什么，需要什么。
如果一上来就用DDD，估计会错失真正的需求。
另外一方面，DDD还是比较偏向软件技术的，而我们的客户绝大部分是不懂开发和技术实现的，什么根、什么继承、什么主键。
使用DDD会让他们很茫然，沟通也会造成障碍。
所以，BA还是需要用之前的方法进行需求的挖掘以及分析。
确定了一些关键对象以及业务规则后，再使用DDD的思想与SA一起进行设计。
此时BA将作为研发团队内的领域专家。
如有必要，我觉得BA在实践DDD的时候，可以参与一些关键的表结构设计和代码评审工作。
写在最后：
其实关于DDD想写的还是挺多的，特别是最近的一些学习心得。
但是有些问题我目前还没有思考的太清楚。
比如在设计的时候何时将一个对象作为一个Entity，何时作为一个Value Object。
结合我们的产品，如果要梳理对象模型，应该是怎样的。
如果你对DDD感兴趣，推荐你这本经典教材《领域驱动设计》，这是小婧今年读的第23本书。
小婧是一名行走在产品路上的资深业务分析师（BA），如果想与我同行，就请关注我吧！