产品框架初步设计后，如何为每个部件定义一个清晰的职责范畴？

Posted 2020-09-19

设计之初，我们必须对整个产品的基本概念和框架有一个初步的设计，这个设计也不可避免地成为整个产品的基础轮廓。

如何定义合理的层数

具体到将要设计的仓库管理流程控制框架产品，首先就要划分为不同的服务层次，而且要找到一种平衡，使得设计既能够将应用划分为有意义、可处理的部件，使它们可以独立开发和部署，同时又要避免过度分解，不能将自己淹没在太多的细节中，从而丧失对整个系统远景的把握或者带来运行问题，如性能、可伸缩性等。本系统将其分为不同的5层，如下图所示。

要注意到，定义的层数越多，端到端的控制流需要穿越的中间层就越多，可能会引入性能问题（特别是在层与层之间是远程的时候）。在同一层内，我们可以再进一步划分为若干易于处理的部分，这些部分应该能够进行独立的开发和升级。这些完备且内聚的职责会被实现为一个单独的领域对象。

这种对仓库管理流程控制系统中不同关注点的严格区分，有助于我们将功能的“大泥球”划分成切实可行的抽象层次，每一层包含具有公共稳定性的元素，从而可以独立地开发和修改而不会影响其它部分产生意外后果。

关注点的进一步细化

仅仅分为不同层次对基于服务组件的软件开发来说粒度太粗了，因为它们仅仅将不同抽象层次的功能关注点区分开，而没有将同一抽象层次不同的功能关注点区分开。例如，仓库管理和物流控制的关注点是完全不同的，但是我们仍有可能在开发过程中将其交织在一起。

问题：怎样将分层系统提炼成更小的、严格划分的领域对象或部件，并为每个部件定义一个清晰的职责范畴呢？

对策：需要为每个完备的、内聚的、功能相关的职责提供一个领域对象（Domain Object），从而严格划分、封装并组件化同一抽象层次上的不同的业务职责。

解决方案：由于系统规模庞大，必须面对多样性业务，而且需求还会不断变化，所以整体上采用面向服务的分布式系统。

从服务的层次来说，总体上分为基础、业务、应用三大服务层。为了便于应用，每个服务层提供了完整的企业服务总线，以集成接口、用户注册、权限管理、安全机制、消息传递等功能。

这样既减少了每一部分规模，也极大地减少了相互之间的耦合性，提升了适应变化的能力。

下图描述了简化的分层结构，对每一个分离出的领域对象，还需要标识出它们的依赖关系，以及相应的接口。

每个服务包是完全独立内聚的，可以独立设计、开发与维护，相互间的接口实现了依赖倒置原则，并且根据用户不同分离了接口，而接口设计切忌主观武断，具体的的做法是：

• 首先确定各个领域对象的依赖关系。

• 凡是具有依赖关系的都设定接口。

• 该结构的详细设计必须等下一层设一完成后再进行。

• 详细设计的时候，首先由上层设计者提出信息的需要。

• 再由下层提供者提出接口的规划。

• 最后由首席架构师做出接口设计的决定。

整个层次接口各层次的说明如下：

在系统的表现层：我们应该区分必须提供的不同“北向网关”和“客户端应用”。

在业务处理层：不论各种类型仓库有多么大的不同，业务处理都包含两个大的部分：“仓库管理”和“物流控制”。我们首先将仓库管理功能和物流控制功能分开，仓库管理功能包含所有的管理性任务，而物流控制功能控制实体层的系统。

在基础设施层：不论何种类型的仓库，有几个基础类型的功能都是存在的，例如：“报表”、“日志”以及“持久化”，这几个不同的功能，如日志、报表和持久化也可以分开。

在访问层：可以为每一个支持的实体层系统提供一个单独的“南向网关”，以实现对实体注意：现实世界的仓库管理流程控制系统中，业务处理、业务对象以及基础设施层包含更多的功能，如警告管理、监控以及安全等，这里作为一个案例，进行了适当简化。此外，根据需要，我们用UML 标记的包符号来表示一个领域对象服务。包符号允许我们表示的领域对象可以像服务一样包含多个组件或类。

本文出自 “中科院计算所培训” 博客，谢绝转载！