ticaje/m2-contract

面向设计(Contract-by-Design)的无偏见模块

安装: 20

依赖者: 1

建议者: 0

安全性: 0

星标: 0

关注者: 2

分支: 0

开放问题: 0

类型:magento2-module

1.0.3 2020-01-29 12:18 UTC

This package is auto-updated.

Last update: 2024-09-29 05:29:41 UTC


README

Latest Version on Packagist Quality Score Total Downloads

前言

当涉及到复杂解决方案时,这是我们这些O.O设计师所追求的,也许需要一种D.D.D(领域驱动设计)的方法。我将简要介绍一下这个惊人模式的某些基础,但为了更多的讨论和贡献,我温和地鼓励您查看我的博客,我们可以就这个问题进行讨论并提出有趣的观点。

尽管这不是我想出来的,但很高兴看到应该声明一个宣言,以便提供关于这个模式代表什么的见解。

安装

您可以使用composer(我唯一推荐的方法)安装此软件包

composer require ticaje/m2-contract

特性

此扩展的主要特性不是任何有形的东西,而是我们在此尝试提供一种不同的(也许)方法,在处理复杂解决方案时可以关注的地方。这是一个为Magento 2不断增长的W.I.P扩展。

以下免责声明是,这个对话空间永远不应该关于针对小/差劲的领域模型的标准程序,那些已经泛滥,在为它们设计解决方案时不需要更大的方法。

领域模型越大,其设计就越复杂。这是设计由合同发挥作用的时刻。当然,在讨论更大的领域建模时,我们应该考虑许多概念,特别是如果我们将要处理期望可扩展、可测试和可维护的系统,尽管我们将重点关注领域层,因为我认为从设计师的角度来看,它是高级解决方案的核心。

尽管如此,有一个概念我们绝对不能忽视,那就是面向语言的开发。

面向语言的开发

不久前,我发现了一篇有趣的文章,提出了(不确定)一个我从未听过的术语,那就是面向语言的开发。请参阅以下发布的文章链接。

这是一个如此伟大的见解,因为它将注意力集中在一个点上,即架构师需要将业务领域与基础设施领域分开。这有时很难实现,因为开发者倾向于认为我们正在使用的工具,例如我们构建解决方案的基础框架,是我们自己的应用程序,并且我们迷失在框架的无数政策和规则中,使得我们的应用程序无法扩展,更不用说我们注定要受框架及其创造者的摆布。

我们将我们的解决方案与框架紧密绑定,以至于如果将来某个时候(也许这种情况永远不会发生)框架消失了,或者我们发现了一个更好的平台,我们就必须丢弃整个解决方案并从头开始构建。

L.O.D的目的是,一切都是API或语言:框架,框架建立在之上的语言,我们的解决方案也是API,我们系统依赖的所有库都受API的约束,我们与外部系统进行交互,我们通过通过标准协议与它们的API交互等等。

因此,架构师的使命是检测和拆分我们领域中的所有组件和参与者,组织依赖关系,以便我们可以定义自己的API以及与其他API的关系。这实际上,根据我个人的谦虚估计,就是L.O.D所代表的。

通过这样做,我们最终创建出服务隔离驱动组件,这些组件不依赖于任何框架,因为通信是通过良好的API进行的,因此我们可以轻松地用最小的努力替换任何组件。

这就是我的朋友,在这里“按设计合同”发挥得最为出色。

按设计合同方法(C.B.D)

回到起点,在一个面向语言的设计是必需的地方,我们有了清晰的路径,开始使事物更容易进行更改、测试等。鉴于一切都是一个API,我们的整个系统都是围绕所有交互(这通常是复杂系统的主要内容)都受到数据和服务合同的约束,以便进行通信这一理念构建的。

与API打交道最令人兴奋的事情之一是我们可以定义接口,在技术上,这是我们系统机械的立法权力。我们通过定义系统组件之间通信的合同来立法,我们解决方案的政策是由这种接口体现的合同,而执行这些政策的工人是这些接口的特定实现。

我们的领域业务规则/政策/约束/行为存在于领域层,这就是为我们的应用程序提供价值并使其与宇宙中任何事物都不同的地方。

通过使用统一建模语言(UML)和标准领域-政策-传输器导向的语言(例如XML)来设计领域模型的架构,我们可以为可扩展性、可测试性和可维护性构建符合D.B.C标准的解决方案。

成长的道路还很长,但我认为值得一试,这样最终会得到我们投入的所有努力、时间和精力。

你注意到这里涉及的概念了吗?如果你注意到了,那不是别的,正是领域驱动设计(DDD),当然,比C.B.D要长得多,丰富得多。但DDD是一个完整的宇宙,值得一本书(至少在较小的情况下)来描述。

面向对象设计模式应用

当然,D.B.C不仅仅是与面向对象宇宙相关联,也与功能设计和其他相关。尽管如此,由于我们将Magento作为参考,因此在原型设计基本思想时,我们关注的是面向对象设计,因此使用了一系列设计模式来体现刚刚说明的概念。

我想说,随着我们进一步深入这个概念,系统成熟度会更强,我们可以使用库来模拟现实生活的问题/解决方案。这是一个针对Magento的方法,但我鼓励你提出不同的、更准确的立场和具体的解决方案,这样我们都可以从中受益。同样,我也想了解我可能引入的任何误解,以便进行纠正将是受欢迎的。

装饰者模式

此模块提供了按照装饰者模式方法向我们的业务类注入行为的空间。

有趣的概念(以及相应的文章)

六边形架构

面向语言软件工程

领域驱动设计

设计模式

贡献

请参阅CONTRIBUTING以获取详细信息。

鸣谢

许可

GNU通用公共许可证(GPLv3)。请参阅许可文件以获取更多信息。