架构整洁之道

海龙2024-9-10读书思想

业务逻辑

业务逻辑：业务逻辑就是程序中那些真正用于赚钱或省钱的业务逻辑与过程。

卖一件产品所得的净利润N元。 这就是商家收入方面的一条业务逻辑，计算是用人还是用计算机并不重要

这种逻辑通常称为 “关键业务逻辑”，而其中可能涉及的商品的成本、卖价等则是 “关键业务数据”。

关键业务逻辑和关键业务数据就是适合放在一个对象中去处理的，这种对象被称为业务实体，代码中分类通常也就是entity.

这种对象要么直接包含着业务数据处理的函数，要么是很容易访问到这些数据处理的函数。业务实体的接口层 （对外暴露可交互的部分），通常是由实现业务逻辑和业务数据处理的函数构成的。

TIP

业务实体应该是系统中最独立、复用性最高的代码。其应处于高层，不应该掺杂用户界面、使用的数据库等无关的东西。

有的业务逻辑，必须要在某个场景下，才是有意义的，这种就不是一个业务实体，可以叫做业务用例

例如：卖个商品可能是网店，那么售卖就需要收集客户地址，联系方式，以及快递公司的预约等。本质上是定义好了需要的输入和输出数据，它并非业务实体中所包含的关键业务逻辑。

用例中包含了对如何调用业务实体中的业务关键逻辑的定义。用例控制着业务实体之间的交互方式

例如：这个用例就要调用业务实体的计算成本，计算卖价，计算出净利润等关键业务逻辑的相关实现，然后再去调用订单，快递等的业务实体或用例的东西

用例是要去依赖于业务实体的，所接受输入应该是请求性结构的东西和输出应该是影响性的结构，但是不该描述和包含系统和与用户之间交互的东西

比如未必是用于web的，所以这些数据接口不应该去依赖具体的像是http标准框架的数据结构的接口。最好创建专门的去依赖于用例的对象去做系统和用户交互等这种最底层的东西。因为用例和这个最底层东西的变更原因和变更速度是不一样的，时间长了，就会变得很乱。

《ObjectOrientedSoftwareEngineering》作者jacobson的观点

软件的系统架构应该为该系统的用例提供支持。这就像住宅和图书馆的建筑计划满篇都在非常明显地凸显这些建筑的用例一样，软件系统的架构设计图也应该非常明确地凸显该应用程序会有哪些用例。

框架通常再文档上,会表现出这些框架是能包揽一切、超越一切、解决一切问题的存在。这不应该成为使用者的观点,那只是框架作者对自己写出来的框架的自信.框架虽然确实强大,但是那都是实现细节时候再去使用的工具而已.

一个系统的架构应该着重于展示系统本身的设计，而并非该系统所使用的框架,不要让系统的架构设计被框架、工具、使用环境等东西影响.特别是我经常接触的web,web只是一种交付方式,它只是io设备,这就是它的角色.

案例

最初的设计目的是帮助单元测试的编写者区分容易测试的行为与难以测试的行为

设计思路其实就是：一组用于包含方便计算机程序来测试的模块，一组则包含难以用计算机测试的部分。

比如：前端展示的GUI上的内容，就属于难测试的东西，这段代码就尽量更简单一些，这样才会更不容易出错，只负责将数据填充到GUI.而数据处理相关的东西放到另一个模块去搞，这样就把一个前端展示的部分拆成了难单元测试的谦卑模块和方便的单元测试的模块