TJX公司的全名叫啥?

Posted 2023-05-13

我需要全名，就是说TJX是什么的缩写呢？表示什么意思？

参考技术A TJX公司总部设在美国波士顿，在北美地区和许多欧洲国家开有连锁分店，仅在美国就有2500多家分店。
　　TJX Companies, Inc. 是美国和全世界的服装和家庭时尚低价零售商。公司经营T.J. Maxx stores, Marshalls stores, and Winners Apparel Ltd. stores。Winners Apparel Ltd. stores是一家加拿大的低价家庭服装和家庭时尚连锁店。公司同时操作HomeGoods, 一家美国低价家庭时尚连锁店；以及T.K. Maxx 、一家在英国、爱尔兰共和国和荷兰的低价家庭服装和家庭时尚连锁店。另外, 公司经营A.J. Wright, 一个新的美国低价家庭服装和家庭时尚商店连锁店。2007年TJX以17516.4百万美元的营业收入和738.0 百万美元的利润额排列世界500强第417位追问

这个不是我要的答案，网上都有

这叫啥类型的架构？

【中文标题】这叫啥类型的架构？

【英文标题】：What type of architecture is this called?这叫什么类型的架构？

【发布时间】：2012-04-01 17:30:18

【问题描述】：

对于我目前正在开发的 Web 应用程序 (ASP.NET MVC)，我们有以下架构：

Data Access Layer: 将数据持久化到任意数据库的逻辑 Domain：数据模型 Service Layer：业务逻辑（如订单处理、账户管理等） Controller：使用服务并向视图提供/接收数据 View：用户的用户界面

本质上，我将Model 拆分为DAL、Service Layer 和Domain。我觉得在Model 中填充所有逻辑会使我的代码过于复杂。此外，我觉得它让我可以清晰地表达我的业务逻辑，而不会让控制器做太多的工作。

那么我的问题是：这种类型的架构叫什么？

第二个问题：这种架构有意义吗？如果没有，我是不是做错了什么？

【参考方案1】：

您在 DDD 方面处于正确的轨道上，具体取决于域和服务层的薄/厚。 DDD 说知识（即业务逻辑）应该被压缩到领域模型中。将数据访问问题移至 DAL 符合 DDD，但我认为将业务逻辑移出服务层则不然。如果您有一个薄的域“数据模型”层（主要用于实体）和一个厚的服务层（主要用于“业务逻辑”），您可能有一个anemic domain。

此外，从技术上讲，DDD 中没有“服务层”。可能有一个“应用程序层”，但它应该很薄，并且只负责应用程序流/管理域类生命周期。这本质上是控制器在 .NET MVC 中所做的，在 web http 的上下文中管理应用程序流。

如果在模型中填充所有逻辑会使您的代码过于复杂，我很想听听您所说的“过于复杂”的示例。您可能正在正确地建模一个复杂的域，或者您可能已经使用 DDD 模式来简化事情。我想说，正如您在问题中列出的那样，拱门不是 DDD。我只称它为“分层架构”，但那是因为我只在谈论物理拱门时更喜欢使用术语“层”。但是，您的逻辑架构是分层的。

我真的很喜欢 Darin 在他的回答中与 Onion arch 相关联。我正在成为它的忠实粉丝，而且我发现它根本不是 DDD 独有的。如果你的代码使用依赖注入来解决运行时实现的接口依赖，你可能有一种洋葱拱的形式。例如，您是否在 DAL 中定义了任何接口？这些接口的实现是否在运行时解决？

这是我开始在新项目中使用的拱门示例。这是洋葱+ DDD的组合：

API Project/Assembly：所有其他层使用的通用接口、枚举、类和扩展方法。不必与域分开，但可以。

Domain 项目/程序集：所有实体和业务逻辑。仅取决于API。使用工厂、服务、规范、存储库等 DDD 模式。还包含更多未在 API 中定义的特定于域的接口。

Impl 项目/程序集：在API 和Domain 中定义的接口的实现。这是实现 EF DbContext 以及日志记录、电子邮件发送等的地方。所有这些实现都是依赖注入的，因此从技术上讲，您可以拥有多个 Impl 项目/程序集。

UI 项目/程序集：这是 MVC 项目。控制器直接使用域表面，不通过应用程序或服务层。工厂、服务、存储库等中的任何接口依赖项都由控制器使用 MVC IoC（构造函数注入）注入到域中。

我在核心放置了一个 API 层，但您可以将 API 和域项目合并为一个。无论哪种方式，洋葱的大肉部分是域，它有内部分层。例如，服务可能依赖于工厂，工厂依赖于存储库，而存储库又依赖于实体。

Impl 项目就是您在巴勒莫图中看到的“基础设施”洋葱皮。它与 UI 一起位于外部边缘，不包含特定领域的知识。它知道如何发送电子邮件、使用 EF 存储/检索数据等。如果您愿意，您可以拥有超过 1 个这些——例如 1 个用于数据访问的 Impl、1 个用于处理邮件的 Impl 等。

MVC 具有控制器和视图，并专注于 UI 和 Web 应用程序流程。任何需要特定领域知识的东西都委托给领域，领域类是注入控制器的构造函数。这意味着域类中的任何构造函数注入接口都由 IoC 容器自动解析。

最后一点，针对 API 和域类中定义的接口进行编程意味着您可以将域项目与 MVC 项目分开进行单元测试。

【讨论】：

你有基于 DDD 的 ASP.NET MVC 项目的好例子吗？或者那些利用你描述的架构的？我一直在尝试阅读尽可能多的 ASP.NET MVC 项目的代码，以收集正在使用的实践，但这非常困难。

在回复您的评论之前，我想和您聊聊：chat.***.com/rooms/9000/danludwig-private-room

这么有趣的答案！我不知道谷歌是如何将我引导到这篇旧帖子的，但这真的很好。您能否在 Code Project 中写一篇关于 DDD 和 Onion 架构的文章并举个例子：) 或者您已经完成了：D

@danludwig 根据 Jeff Palermo 的说法，您的 API 不应该被称为 Core 吗？我会调用API 更多的外部层，例如Application Services 或结合Application Services 和Domain Services

【参考方案2】：

从高层次上讲，我将其描述为分层架构。将其描述为领域驱动设计也会考虑较小的模式，例如聚合、存储库、有界上下文等。我无法仅从您的描述中判断。

如果域层位于不引用任何其他组件/包的程序集/包中，则它具有Onion Architecture principles 的核心，它们是：

应用程序是围绕一个独立的对象模型构建的 内层定义接口。外层实现接口 耦合方向朝向中心 所有应用程序核心代码都可以独立于基础架构进行编译和运行

要查找的具体内容是您的 DataAccess 是否引用域。

【参考方案3】：

根据您从哪个角度看，可能会有不同的名称。所以它仍然是MVC，只是你的M被分成了多层。它也可以称为Multitier architecture（或 N 层架构）。 Jeffrey Palermo 也使用了Onion architecture 的概念。

【参考方案4】：

由于您将 DAL 与域模型分离，并且还具有服务层，因此看起来您正在前往 DDD（域驱动设计）这里是关于此类 an approach 的讨论，这可能对了解很有用。

【讨论】：

+1 正是我的想法。 MVC 应用程序使用的 DDD。取决于模型有多薄（或服务有多厚）。