Java程序分层架构

近年来，我在IT公司遇到过很多因软件架构不正确而导致的问题。 不正确是什么意思？ 在大多数情况下，这是一个方向——相对于它应该解决的问题来说：要么过于简单要么极其复杂</

许多开发者将Clean架构的图示直接转化为项目结构，但作者指出，Clean 架构实际上不是关于文件夹的，而是关于依赖关系的管理。 传统的基于技术分层的代码组织方式会导致相关组件分散在多个项目中，违反了共同封闭原则，隐藏了依赖关系，缺乏业务意图，并且

项目的结构与讨论空格与制表符或缩进大小一样敏感。当我们进入某人的公寓时，即使它是根据宜家的默认设置进行装饰的，它看起来也总是有些不同。这是绝对合理的。不同的公寓大小和房间布局会有所不同。它类似于我们的软件项目。每个都有略微不同的假设和特征，但可以区分出一些共同的特征，对吗？和

我们将讨论为什么编写更多可读的代码，而不是简明（短）的代码。之后，以下是关于如何做到这一点的策略： 变量、类和函数的命名 辅助函数 代码注释 枚举/字典/密封类/等等。 包的组织和命名 <

目标 提前计划并遵循模式或风格可以让开发人员更好地了解每个组件的职责，并让开发人员能够专注于较低级别的细节。 熟悉许多软件架构模式并了解每种模式的优缺点对于选择最适合功能要求的模式至关重要，并且最终很可能会导致更好和更容易的实现。

本文将在 Java 中实现 Hexagonal Architecture 的基本概念。 六边形架构：六边形架构是一种用于设计软件的架构模式。它旨在创建以核心业务逻辑或领域为中心的松散耦合的可互换软件组件。

敏捷方法现在可能很普遍，并且有了它，增量方法的概念应该被开发社区所了解和利用。尽管如此，在与开发人员交谈时，我仍然发现它的理论与它在日常开发实践中的应用之间存在脱节。 我认为这种脱节部分是由于我们分层构建解决方案的方式，以及我们在创建用户故事和最终

本案例github源码是一个六边形架构的单体案例，非微服务案例。 首先，包的形式：1、把领域和基础设施分开。领域是你所有的业务逻辑、数据库模型、你的服务、DTOs、异常、端口接口和所有对你的领域来说重要的东西。有些人可能会争

软件架构和软件设计是同一主题的两个方面。两者都是关于如何构建软件以执行其任务。术语“软件架构”通常指软件系统的较大结构，而“软件设计”通常指较小的结构。 架构和设计之间的确切界限很难说，因为系统的架构也会影响其设计。较大结构的设计会影响较小结构的设计。</

在Spring中，@component、@service、@Controller和@Repository注释称为构造型注释。当启用组件扫描时，Spring会自动将这些bean导入到容器中，并将它们注入到依赖项中。 它们都用于将类标记为Spring管理的组件

干净的代码是不够的——内聚是一个系统级的问题： （敲黑板）同学们注意啦！今天咱们要聊的是一个超级重要的编程概念——"代码团伙的凝聚力"！别看名字高大上，其实就跟咱们班分组做值日一个道理！

大多数写软件的团队会习惯性地把代码分成几层（比如控制层、服务层、数据库层），或者按技术工种分（比如做页面的/做后台的、做接口的/管数据库的）。这么分乍一看挺整齐，大家都熟悉，感觉也挺踏实。但是当软件越做越大时，就开始出些麻烦事了。 比如你只改了一行业务逻辑

前两天我特意去打听现在那些时髦的SPA前端用的REST程序，代码量跟淘宝、B站这种级别差不多大。我这种老Java程序员觉得最顺手的写法就是： controller控制流程、 service干脏活累活、 entity当数据模型、 repository管仓库、 <