关键业务怎么写(架构整洁的业务逻辑分享)

关键业务怎么写(架构整洁的业务逻辑分享)

业务逻辑就是程序中真正用于赚钱或省钱的业务逻辑与过程。例如:银行要对贷款收取N%利息这个逻辑就是银行获取收入的一条业务逻辑。

“关键业务逻辑”通常会需要处理一些数据,例如,在借贷的业务逻辑中,我们需要知道借贷的数量、利率以及还款日程。我们将这些数据称为“关键业务数据”。关键业务逻辑和关键业务数据是紧密相关的,所以它们很适合被放在同一个对象中处理。我们称这种对象为“业务实体”。

1.1 业务实体

业务实体包含了一系列用于操作关键数据的业务逻辑。这些实体对象要么直接包含关键业务数据,要么可以很容易访问这些数据。

例如借贷业务实体类的UML图:

架构整洁的业务逻辑

该类将具体的业务逻辑聚合在一起,并且与系统中其他部分隔离区分。这个类代表了整个业务逻辑,它与数据库、用户界面、第三方框架等无关。即业务实体中只有业务逻辑,没有别的。

需要强调的是:业务实体不一定非要用面向对象编程语言的类来实现。业务实体只要求将关键业务数据和关键业务逻辑绑定在一个独立的软件模块内。

1.2 用例

用例本质上就是关于如何操作一个软件系统的描述,它定义了用户需要提供的输入数据、用户应该得到的输出信息以及产生输出所应该采取的处理步骤。当然,用例所描述的是某种特定应用情景下的业务逻辑,并非业务实体中所包含的关键业务逻辑,并且也不详细描述用户界面。

1.3 请求和响应模型

通常,用例会接收输入数据,并产出输出数据。但是在一个设计良好的架构中,用例对象通常不应该知道数据展示给用户或者其他组件的方式。也就是说不希望用例类中出现HTML和SQL。

因此用例类接收的输入应该是一个简单的请求性的数据结构,而返回输出的也要是一个简单的响应性数据结构。而不应该派生自HttpRequest和HttpResponse等。也不应该了解任何有关用户界面的细节。

在开发过程中,我们会在数据结构中使用对业务实体对象的引用。因为业务实体和请求/响应模型之间有很多相同的数据。但是千万不要这么做!这两个对象存在的意义不一样。并且随着时间的推移,这两个对象会以不同的原因,不同的速率发生变更。如果整合在一起将会违反共同闭包原则(CCP)和单一职责原则(SRP)。会导致代码中出现很多分支判断语句和中间数据。

总结一下:业务逻辑应该保持纯净,不要掺杂用户界面或者数据库相关的东西。业务逻辑应该是系统中最独立、复用性最高的代码。

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至 1727195746@qq.com 举报,一经查实,本站将立刻删除。
(0)

相关推荐

发表回复

登录后才能评论