What
面向方针
作为一名程序员，代码编程咱们平常伸手就来。日常用到比较多的言语或许是 Java、TypeScript、C++ 等，大家都很清楚，这些都是面向方针的言语。那么问题也随之而来，是咱们需求运用面向方针的特性才挑选了这些言语开发，还是随声附和地挑选了这些言语开发？
在面向方针的理念中，万物皆方针。面向方针的精髓在于笼统，面向方针的困难也在于笼统。简略来说：面向方针的成功在于成功的笼统，面向方针的失利在于失利的笼统。
方针与方针之间都是孤立的，比如现实日子的你和我之间。只有在特定的场景下，孤立方针之间进行了某些信息交互才表示出一个场景进程，比如依据这篇文章，你和我之间才建立起了作者和读者的联系。
面向进程
已然说到面向方针，就还应该了解到另外一个选项：面向进程。面向进程认为咱们的国际是由一个个相互相关的消息同组成的，这是一种类似 螺旋式 的结构，每个小体系都有明晰的开端和明晰的结束，开端和结束之间有着严谨的因果联系。在面向进程的规划办法中强调将问题分解成小的、可重用的模块，每个模块负责履行特定的任务。
Talk is cheap. Show me the code！ 咱们联想下日子中是怎么购物的？浏览产品 → 加购 → 结算 。转换成对应的伪代码，应该是这样的：
这很契合咱们平常的代码风格，但也的确是一种面向进程的规范写法。感到一丝惊讶和矛盾，难道咱们平常都在用面向方针言语来写面向进程的代码？事实的确如此。咱们平常的办法封装调用很大一部分便是面向进程的规划。
这里并非是说 面向进程 的写法不正确，反而在某些场景下面向进程愈加直观。但面向方针的规划为何而来？
哪怕咱们平常大部分做的都是 CRUD 的作业，重复性的代码也会构建出一个巨大的体系。构成一个体系的因素太多，要把一切问题的因素都考虑到，再把一切因素的因果联系都剖析清楚，接着把整个进程都用代码表述出来未免太过于困难，这不仅对创作者来说是一个灾祸，对后继者来说更是：talk is cheap, code is shit ！
咱们转换下思维，怎么运用面向方针的特性规划以上代码？运用面向方针的办法论，万物皆方针。
那么由此可以规划出 产品、购物车 以及 付款 的方针
How
作为开发，咱们作业的实质便是把一个产品需求转化成一个可以运转的体系，中间或许会触及产品规划、需求建模、架构规划、完结规划、代码编写等众多过程。
在调研需求时常常会堕入面向进程的误区，咱们会最先弄清楚有多少事务流程，接着画出事务流程图，然后顺藤摸瓜，找出事务流程中每个要害过程，弄清楚上下文是怎么传递的。
事实上，架构规划、完结规划、代码编写都是归于软件开发的阶段。在规划之前，咱们假如有一个明晰的方针，那后边的举动无疑会变得顺利许多。咱们面临着成百上千的需求，每个需求或许都存在错综杂乱的联系，杂乱度并非是线性增长的。需求杂乱度是否相等于技能杂乱度？
面向方针编程意味着编写针对建模方针的代码。这是用于描绘杂乱体系动作的众多技能之一。它是经过描绘交互方针的数据和行为来界说。
那么在编程之间咱们就需求进行很要害的一步：建模。
ChatGPT：建模是指对客观事物建立一种笼统的办法用以表征事物并取得对事物自身的了解，一起把这种了解怀念化，并将这些逻辑概念组织起来，构成一种对所调查方针内部结构和作业原理便于了解的表达。
公式：静态的事物（物）+特定的条件（规则）+特定的动作（参加者的驱动）=特定的场景（工作）
当咱们尝试为需求背面的场景建模时，首先要决定便是笼统的视点，这一步特别重要也特别不易。一旦笼统视点确认，后边的规划就变得水到渠成，而不是杂乱无章。
这一步也是与 面向进程 的主要差异地点：
- 面向进程：希望可以通盘考虑，把一切问题的因素都考虑到，再将这些因果联系理清，这就会将结构变得很杂乱。（把工作杂乱化）
- 面向方针：希望可以把杂乱的事物经过合理的笼统视点分解成小块，每个小块之间独自考虑，最终再依据特定的场景将块与块之间串联。（把工作简略化）
因而面向方针的要害就在于刚开端面临问题范畴的时分不要决定去全盘考虑，而是找出问题范畴里包括的笼统视点，只需笼统视点找对找全，那么通盘的问题也就层层解决。当然，在笼统的进程中，每个视点之间或许是互不相关的。
做需求的时分，首要方针不是要弄清楚事务是怎么一步一步完结的，而是要弄清楚有多少事务的参加者，以及每个参加者的方针是什么。而这其间参加者的方针便是你需求笼统的视点
笼统视点
笼统的层次越高，详细信息越少，对应的概括能力越强。
- 自顶向下： 自顶向下的办法适用于让人们从头开端知道一个事物。先微观后微观
- 自底向上：自底向上的办法适用于在实践中改善和进步知道。先微观后微观
映射到咱们的软件开发进程中，咱们往往会采用自顶向下的办法，先搭建一个框架，用少数粗粒度的概念来掩盖体系的需求，再逐渐细化，降低笼统的层次。一起在细化的进程中，咱们也可以经过细节间的相同之处，来改善较高层次的笼统规模。因而这两种办法应当是相得益彰，而不是两者择一的联系。
依据笼统而成的方针理应具备以下特征：
- 方针都具有原子性 无论在什么时分，在同一笼统层次上，在剖析进程中都应当将方针视为一个不可分割的原子，哪怕这个方针的规模很大。
- 方针都是可笼统的 方针所具有的方面，或许说方针所参加的场景越多，方针越有笼统价值，反之则越没有笼统价值
- 方针都有层次性 方针是有着笼统层次的。层次越高，其描绘越大略但适应能力越广；层次越低则描绘越精确但适应能力越下降
参加者
参加者的人物在建模进程中是处于中心地位的。他们是处于体系规模之外，居于事务规模之内与体系进行交互的。
什么是参加者？简略界说如下：
- 谁将运用此功用
- 谁对某个特定功用感兴趣
- 谁负责支撑和保护体系 参加者一定是直接而且主动地向体系宣布动作并取得反馈的，否则就不是参加者
在实践事务剖析阶段，咱们需求区别 事务规模 和 体系规模
- 事务规模：是指项目所触及的悉数客户事务范畴，不论是否触及开发体系的参加，这些事务都是客观存在的
- 体系规模：是指软件体系将要完结的那一部分功用，这些功用是从事务规模中提取，是事务规模的一个子集
假如在事务剖析阶段就预设了核算机体系的存在，那么将会混淆现有事务和将来实践开发的事务，将用户代入到核算机体系中，或许会造成现有事务特点的削弱，而疏忽了实践事务背面的含义。
当然，这也是开发人员对接事务需求的一大误区之一。喜爱从核算机体系的视点来考虑问题，在向客户搜集需求的时分总是在第一时刻想到核算机将怎么完结它，常常津津有味于跟客户讨论背面的体系将怎么完结客户的需求，而且指望客户可以用这种办法来承认需求。带来的危害：
- 客户不能了解将来的落地完结是什么姿态的，可是出于信任开发人员，就会将信将疑地做出肯定
- 开发人员在一开端就加入了自己的片面判别，假设了事务在核算机体系里的完结办法，而没有实在地去了解客户的实践事务
用例
用例是一种描绘体系怎么与外部用户或其他体系进行交互的技能东西。它描绘了体系的功用和行为，并以用户的视点来描绘体系的需求和运用场景。简言之：用例是用来捕捉功用性需求
在软件开发阶段，咱们会以用例作为最小指导单元进行规划，规范的用例应当具备以下特征：
- 用例是相对独立的
- 用例的履行成果对参加者来说是可观测的和有意义的 用例的粒度巨细不是从用例包括的过程的多少来判别的，而是每一个用例能尽量可以阐明一件完好的工作
用例的获取并非来历于开发人员，换言之，开发人员是用例的翻译者。用例的界说是参加者驱动的，这也对应了用例的特征之一：用例的履行成果对参加者来说是可观测的和有意义的。因而用例的来历便是参加者对体系的希望。所以发现用例的前提条件便是发现参加者，确认参加者的一起就确认了体系鸿沟。
Code without understanding the business is like playing the rogue
结合事务，与参加者聊需求的时分常常感觉需求飘渺不定，每个点都感觉是需求的中心部分。那么是否有仔细想过：参加者想做和要做的工作不一定是他实在的方针，或许仅仅他做工作的一个过程
- 一个明晰有用的方针才是一个用例的来历
- 一个实在的方针应当完备地表达参加者的希望
- 一个有用的方针应当在体系鸿沟内，由参加者发动，并具有明晰的后果
在软件开发需求耗时最久是哪个阶段？应该是需求剖析和规划阶段。为了缩短开发周期，很简单想到便是减缩需求剖析和规划阶段的时刻，当你真的这么做了，你或许就会离实在的用例愈偏愈远！要平衡时刻和质量，就需求充分了解用户需求，当访谈不顺利的时分应当重新调整战略，调全体系鸿沟的规模或许替换访谈的参加者都是不错的挑选。
用例不是功用点
在大多数开发者看来 用例是一个功用点。但是实践情况并非如此。功用的生命周期：输入->核算->输出，功用是脱离运用者的愿望而存在的，自身是孤立的。
类似一个判别用户是否有操作权限的办法，这个办法自身是脱离事务的，它的用例场景或许是用户在提交某个模块下的改变记录，才需求校验权限，而校验权限仅仅其间的一个功用。
在实践情况下，更应当从运用者的观点去描绘，一个用例是一个参加者怎么运用体系，取得什么成果的一个集合，那么此刻用例可以解释为一系列完结一个特定方针的功用的组合，针对不同的使用场景，这些功用可以以不同的组合办法构建出新的用例。
过程不是方针 一个用例是参加者对方针的一个希望。在完结这个方针之前需求经由许多过程，但每个过程并不能完好地反映出参加者的方针，因而作为一个用例是有所缺点的。过错地运用过程作为用例，将无法精确地描绘参加者怎么运用体系，全体体系的操作流程以及交互细节会产生偏差，脱离预期。
方针和过程很简单造成混淆，在弄清楚方针与过程之前，咱们就需求设置一些实践场景来解释，经过场景中触及到的问题来测试出什么才是参加者实在的目的。
或许在此之前参加者也不清楚自己想要的究竟是什么！
至此，回想《范畴驱动规划-软件中心杂乱性应对之道》自面世以来，带来了一个全新的思维：范畴驱动规划。重点传述的也是经过范畴规划来分离事务杂乱度和技能杂乱度。杂乱度或许永久不能消除，但咱们可以剖析杂乱度，从而办理杂乱度。书中有说到：
每个软件程序是为了履行用户的某项活动，或是满足用户的某种需求。这些用户使用软件的问题区域便是软件的范畴。
回过头来看上述所讲到的面向方针，不乏有相同之处。某种程度上，把“范畴驱动规划”改为“模型驱动规划”也相当恰当。
收回开头的问题，我认为：需求杂乱度 != 技能杂乱度，建模理应成为咱们办理杂乱度的东西！
本篇文章的思维路线：
最终以 ChatGPT 来个结束
面向方针编程在与事务需求结合时展现出非凡的优势，经过将事务需求映射为方针和类的组织结构，咱们可以更好地了解和办理杂乱的事务逻辑。
经过面向方针的办法，咱们可以将事务需求转化为详细的方针和类，从而更好地了解和模仿实在国际中的事务流程和实体。经过封装数据和行为，咱们可以将杂乱的事务逻辑划分为独立的方针，每个方针负责特定的功用和职责。这种模块化的规划使得咱们可以更好地了解和办理事务需求，一起也为将来的扩展和修改提供了便当。
