腾讯云开发者社区-腾讯云

开发者社区

文档建议反馈控制台

最新优惠活动

文章/答案/技术大牛

发布

物流IT圈

专栏作者

280

文章

502789

阅读量

97

订阅数

物流仓储系统的分析与设计（一）

物流的发展不仅与社会经济和生产力的发展水平有关，同时也与科学技术发展的水平有关。按照时间顺序，物流发展大体经历了以下阶段：20 世纪初，在北美和西欧一些国家，随着工业化进程的加快以及大批量生产和销售的实现，人们开始意识到降低物资采购及产品销售成本的重要。

2021-12-28

1.1K0

领域驱动设计（DDD）理论启示

系统架构架构设计微服务 uml

过去几年通天塔一直处于快速的业务能力建设和架构完善的阶段，以应对不断增长的业务需求和容量、高可用等技术需求，现在通天塔平台已经能满足集团主站的大部分活动、频道搭建和运营能力，主流程的新需求越来越少，个性化需求和非标准化流程的数据源和服务接入的需求越来越多，有些甚至是京东零售体系外的，同时通天塔技术和产品也在积极主动寻求变化和创新，这些因素结合在一起驱动通天塔孵化出了一个以技术为导向的项目：通天塔积木，旨在构建一个基于完全开放的前端SDK和后端数据源&服务、高度灵活和强大的积木画布、能够快速移植和部署到任何第三方IT环境的活动搭建解决方案，这套方案的初衷和设计理念也契合了京东国际化赋能和PaaS化的战略。目前通天塔积木已经取得阶段性成果，已开始赋能京东国内和国际站，但如何应对异常复杂的积木业务逻辑和不可预知的业务变化，构建业务和底层技术基础实施的完全解耦的系统，一直是我们面对的巨大挑战。也是时候从更高视角来看清问题和源头，思考一种能应对和控制业务复杂度、具备强扩展性和弹性的解决方案。纵观我们的目标，DDD这个词不知不觉映入了我的眼帘。

2020-03-16

1.5K0

Spring Web 应用的最大败笔

spring 网站 uml

开发人员在使用Spring应用是非常擅长谈论依赖注入的好处。不幸的是，他们不是那么真的利用它的好处，如单一职责原则，分离关注原则。如果我们一起来看看大部分Spring的Web应用程序，常见的错误的设计如下： 1.领域模型对象用来存储应用的数据(当作DTO使用)，领域模型是贫血模型这样的反模式。 2.服务层每个实体有一个服务。问题是这样很普遍，错误在哪里呢？ Spring的web应用程序之所以这样是因为他们做事物的方式一直都是这样做的，老习惯难改，特别是如果他们是高级开发人员或软件架构师，这些人捍卫这样做的论据之一是：我们的应用程序遵循关注分离的原则，因为它已经被分为若干层，每个层有自己的特定职责。 1. Web层负责处理用户输入，并返回正确的响应返回给用户。 web层与服务层通信。 2.服务层作为一个事务边界。它也负责授权和包含我们的应用程序的业务逻辑。服务层管理的域模型对象，并与其他服务和存储库层进行通信。 3.存储库/数据访问层负责与所使用的数据的存储进行通信。分离关注(Soc)是分离计算机程序为不同的部分，每个部分有一个关注聚焦，一个典型的Spring Web应用在一定程度上遵循这一原则，但现实是，该应用程序有一个整体的服务层，它有太多的责任。更具体地，服务层有两个主要问题： 1.在服务层发现业务逻辑业务逻辑被分散在各个服务层。如果我们需要检查一个业务规则是如何实现的，我们必须先找到它。这可能并不容易。此外，如果相同的业务规则需要在多个服务类，问题是，规则需要从一个服务到另一个简单地复制。这将导致维护的噩梦。 2.每个领域模型一个服务这完全违反了单一职责原则，它被定义为如下：单一职责原则指出，每一个类都应该有一个责任，责任应该由类完全封装。其所有的服务应该狭义与责任相一致。(不应将原属于领域模型的行为方法等划放在服务中实现，对象不但有属性还有行为) 服务类有很多依赖，以及大量的循环依赖。更像网络紧密耦合和单片服务。这使得很难理解，维护和重用。这听起来有点苛刻，但一个Spring的web应用的服务层往往是最容易出问题的部分。幸运的是，所有的希望都不会丢失。 1. 我们必须将我们的应用程序的业务逻辑从服务层迁移到领域模型类中。举个例子：假设我是一个服务类，你是一个域模型对象。如果我让你从屋顶上跳下来，你会喜欢我这样的决定吗？(跳下来会摔伤，自己没有脑子或被洗脑，变成僵尸，只听从执行，不思考自己的安全，这就是贫血模型的问题) 将业务逻辑从服务层迁移到域模型类有下面三个优势： (1)我们的代码将以逻辑方式切割，服务层只要关注应用逻辑，而我们的领域模型关注业务逻辑。 (2)业务逻辑只存在一个地方，容易发现修改。 (3)服务层的源代码是清洁的，不包含任何复制粘贴代码 2. 将每个实体服务切割为单一目标的更小的服务。比如，有一个单一服务类，提供对人员和用户账户的CRUD操作，我们应该将它分为两个独立的服务类：第一个是对人员的提供CRUD操作第二个是提供与用户账户相关的操作。好处：每个服务类中有一个逻辑组职责。每个服务类的依赖较少，这意味着他们不再是紧耦合的源头。他们是较小的和松耦合的组件。服务类更容易理解，维护和重用。这两个简单的步骤将帮助我们使得我们的应用程序架构更干净，有助于同行开发商提高生产力和幸福。

2019-12-11

3430

多研究些架构，少谈些框架

微服务数据库 sql uml

微服务现在辣么火，业界流行的对比的却都是所谓的Monolithic单体应用，而大量的系统在十几年前都是已经是分布式系统了，那么微服务作为新的理念和原来的分布式系统，或者说SOA（面向服务架构）是什么区别呢？

2019-09-24

5590

没有更多了

社区活动

腾讯技术创作狂欢月

“码”上创作 21 天，分 10000 元奖品池！

Python精品学习库

代码在线跑，知识轻松学

博客搬家 | 分享价值百万资源包

自行/邀约他人一键搬运博客，速成社区影响力并领取好礼

技术创作特训营·精选知识专栏

往期视频·千货材料·成员作品最新动态