Java程序分层架构

Hexagonal Architecture(六角形或六边形) 于2005年由Alistair Cockburn撰写，是一个具

看！看！深入研究自然，你就会明白一切。 - 爱因斯坦(点击标题)[该贴被banq于2014-09-12 08:19修改过]

到底什么是抽象？我们经常说和听到“抽象”这个词，但是大家可能并不特别理解这个词到底是什么意思，至少大家对这同一个词的理解感觉起来有很大的不同，我想表述一下我的理解。什么是抽象？什么是抽象程度高？什么是具象？我天天说抽象，甚至我还在比较抽象的程度的高低，我费劲琢

本文是一篇从业务开发人员角度发出的批判性文章，技术发展日新月异，但是好像都没有真正解放业务开发工作量，对软件复杂性的抱怨是软件行业发展过程中不断出现的现象，其实如何在代码快速开发和代码灵活性方面找到一个结合点，业界其实没有找到规律或者理论，或者都没有所谓不可能定律，也就是说，快速和灵活是不可能同时具

在我看来，软件架构与建筑物的架构非常相似。你可以建造一个没有精心建筑设计的房子，但它永远不会是完美的。如果没有好的计划，你就无法建造一座大楼。在规划阶段，您需要注意几个想法：选择正确的墙壁，规划电力，水系统，所有房间，照明系统，空调和暖气等等。所以这是一项复杂，困难但必要的工作。在软

看到 领域驱动设计精简版 开始部分有一个图，一直不解1.图中的箭头是什么意思，是引用关系？2.UI层为什么跳过应用层会直接引用 Domain层，1数字位置？3. 2 数字位置，为什么有 两根箭头， 难道 a 、b 代表不一样，其它层也是一样，有多个框。[该贴被

Netflix分享了其如何使用Node.js+React.js替代原来的Java + JQuery传统架构，从而让网站页面加载更快，用户体验UX更好。 性能很重要。Netflix的会员希望一打开浏览器就能立即开始观看他们喜爱的内容，更快的启动才能有更令人满

传统应用程序架构的标准三层或四层模型似乎决定了系统中各种对象之间的依赖关系的方向：UI依赖于应用程序层，因为UI“驱动”后面发生的事情；应用程序层依赖于业务对象，业务对象执行所有特定于领域的事务，业务对象使用（因此依赖于）持久层和通信层，这两个层又使用并依赖于外部API。以这种方式实现分层模

您好各位大牛，最近在研究Jdon 框架，在看介绍时看到JF关键技术特点中的第2点:事件驱动架构Event-driven Architecture(EDA) ,异步领域事件,并发策略, 懒惰加载，异步消息机制，结合JMS可实现大型分布式可伸缩的架构, 6.4整合入号称最快的并发框架Disrup

容器这个词取的好容器这个词取的好啊，叫“容器”可能是在暗示人们建议人们用空间去思维系统。“注入”这个词也好，“注入”肯定也是在暗示空间维度。图1

把M分成5层，A层： Application 应用层B层：Business 业务层C层：Component 组件层D层：Datadriver 数据驱动层S层： Systemdriver 系统驱动层

过去我们想到3层模型、领域分层，然后总想到存储层总放在底层，或许不是只是单单的存储层。 这种思考定势是先入为主，还是自然习惯呢？这里我提出一种假设，若果存储层（数据库）只是一个页面，所有持久化都认为是一种单纯的输出，这是一种怎样的情况呢？或者有人会问“存储

在看论坛，发现不怎么明白实体和一般值对象的区别，什么是实体？ 在我们开发的项目中，我们在DAO层采用的对象是BO，然后在传输层，我们把BO-->DTO,最后在显示层，我们把DTO-->VO,页面采用VO来进行开发，我觉得这样转换效率很低，但是从分层的角度来看，每层有每层想表达但是不

就像维基百科建议的那样，KISS是一个缩写保持简单，愚蠢作为美国海军在1960年提出的设计原则.KISS原则指出，如果保持简单而不是复杂化，大多数系统都能发挥最佳作用; 因此，简单性应该是设计中的关键目标，并且应该避免不必要的复杂性。根据我的经验，我研究

在查看代码时，我经常会看到MVC模式：模型，视图，控制器，表单等文件夹。表面上看起来不错，对吗？您将控制器放在控制器文件夹中，模型文件夹中的模型等等。这对于像博客这样的小型示例应用程序来说相当不错，因为您可能有5个控制器，6个模型等等。但是，当您在更大的应用程序上工作，或者您遵循

如果将web层 和service 层 分开做集群 是不是需要分开部署 ！ 而且之间是需要走接口通信 ？ 希望有经验的 给指点下