本文主要是介绍css 六角形_揭开六角形的神秘面纱，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
css 六角形
传达好主意需要很大的隐喻。 六角形不完全是其中之一。
当我第一次遇到六角建筑时，我感到非常震惊。
这是用于构建系统的如此简单但功能强大的架构模式。
然而，由于Alistair Cockburn为传达他的想法所做的选择不佳，我在努力了解其本质之前一直在努力。
在我的“ 隐喻驱动设计”一文中 ，我解释了当两个域之间的ligamen过于线程化时，如果未正确选择隐喻框架，则除了隐喻作者以外的其他人都将难以获得 它 。
这正是六角建筑所发生的。
您的系统中有一个核心，即业务逻辑 。 然后周围有一些接口。 以及周围的外部环境。
虽然这是六角建筑的关键概念，但阿利斯泰尔（Alistair）的隐喻建立在非常不寻常的前提下，以至于他甚至感到有必要解释为什么选择这个名字。
六边形不是六边形，因为第六个数字很重要，而是允许进行制图的人员有足够的空间根据需要插入端口和适配器，而不受一维分层图的约束。 术语“六边形建筑”来自这种视觉效果。
术语“端口和适配器”是指图纸各部分的“用途”。 端口标识有目的的会话。 对于任何一个端口，通常会有多个适配器，用于可能插入该端口的各种技术。 通常，这些可能包括电话答录机，人类语音，按键式电话，图形人机界面，测试工具，批处理驱动程序，http界面，直接的程序对程序界面，模拟（在-内存）数据库，一个真实的数据库（可能用于开发，测试和实际使用的不同数据库）。
用两个替代名称（ Hexagonal Architecture ， Port和Adapters ）发布新发明的模式是不寻常的。 我认为发生这种情况的原因恰恰是因为Alistair无法提出一个更好的独特名称来代表他的新想法。
那么，为什么我要花时间和言语谈论隐喻？
因为这是有史以来最有用的架构模式之一 ，但由于这些名词带来的认知失调，开发人员仍在努力抓住其本质。
我想修复它。
核心思想
您的业务逻辑是系统的中心。
不会散布在很多地方，而是散布在一个与世界其他地区无关的单一代码内核中 。
在它周围，有一个或多个接口。 它们是人或外部系统与业务逻辑之间的中介。
接口完全在业务逻辑的下游 。
这意味着，当业务逻辑的表面发生某些变化时，所有接口都必须适应。 当界面表面发生变化时，业务逻辑将不在乎。
这是六角建筑的本质 。
“ 数据方面呢？ ”-您可能会问。
我认为，正如Alistair所描绘的，与数据端的关系在与具有接口的关系方面起着次要的作用。
选择您自己的数据表示方式比处理外部输入要简单得多。
这是有史以来最有用的架构模式之一 ，由于这些名词带来的认知失调，开发人员仍在努力捕捉其本质。
为什么要使用它
因为它专注于最重要的事情 ，即业务。
您如何与之互动是次要的。 该技术，协议被推到系统的边界。
API，用户界面，CSV文件，CLI客户端。 所有这些仅是服务于独特目的的手段。
如果您希望系统始终如一地工作，那么这是一个很好的起点，因为所有知识和所有约束都集中在一个地方。
让我们举个例子。
您有一个保留电子邮件地址记录的系统。
人们应该通过HTTP API通过Web应用程序和外部系统与人类用户进行交互。
在添加新的电子邮件地址之前，您首先要检查系统中是否已存在该电子邮件地址。 如果存在，则不要添加两次。
这是系统的约束。 这是您的业务逻辑。 无论我们用来与之交互的接口如何，它都将执行。
因此，您应该将此约束放在一个地方。
我喜欢这种DRY ：知识； 约束 商业逻辑。
假设现在您想将一个人与这些电子邮件相关联，并且您有两个要求：
- 该人的名字不能为空；
- 该人必须上传个人资料图片；
您如何确定业务逻辑中的内容以及界面中的内容？
答案是： 看看必须在哪个级别应用约束 。
在情况＃1中，这是您的业务逻辑的约束。 不允许使用任何接口将具有空名的人与现有电子邮件地址相关联。
而且您也不想在每个接口中复制约束。 同样，这就是DRY的目的。
在情况2中，这仅是对人类的约束。 因此，它应该放在Web应用程序中。 业务逻辑永远不会知道任何个人资料图片。
如果您想让人类用户可以通过API上传他们的个人资料图片，该怎么办？
完全合法。 在这种情况下，您将再次实现六边形体系结构模式，这一次仅在您的Web应用程序周围。
六角形建筑图案是分形的。
另一优势
您听说过CQRS吗？
自问世以来，它变得越来越受欢迎。
仍然有很多开发人员在实施体系结构决策时遇到困难。
六角架构的好消息是它自然地引入了CQRS。
您的业务逻辑是只写的。 您的界面各自拥有一个读取模型，并将命令代理到业务逻辑。
就是这么简单。
“ 为什么要为每个接口读取模型？ ”-您可能会问。
因为每个界面都为不同的用户或目的服务。 因此，需要不同的数据表示形式。
读取模型是决策支持系统。
因此，仅当它是专门针对接口专用的用户类型和用例而设计时才有用。
这就是为什么我使用以下启发式方法： 针对每种类型的系统用户的一个界面 。
如果将业务事件发布到发布/订阅基础结构中，则很容易构建许多读取模型。
您可以让每个接口的一个侦听器选择相关事件，并将它们投影到接口读取模型中。
使用发布/订阅消息传递模式，您的六角体系结构得以保留，因为业务逻辑仍然无法确定其周围的所有事物。
它只是发布消息。 谁来接他们并不重要。
结论
我对“六角形体系结构”以及如何以更实际的方式解决它作了一些说明。
即使原始名称引起了很多混乱，我也避免给该模式起任何新名称。 相反，我专注于解释其本质。
我还向您展示了如何将它与CQRS组合成一种极为有效的体系结构。
关于这种出色的模式，还有很多话要说，我还没有回答一些问题：
- 接口和业务逻辑之间的通信协议应如何显示？
- 您应该如何内部构造业务逻辑？
- 业务逻辑的不同部分如何相互通信？
我将在以后的文章中向您展示这些以及更多奇迹。
现在我只能说：谢谢阿利斯泰尔。 我感谢您提供的这份令人惊奇的知识礼物。
翻译自: https://hackernoon.com/demystifying-the-hexagon-5e58cb57bbda
css 六角形
这篇关于css 六角形_揭开六角形的神秘面纱的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
