哈Ha今天，我去了
Slack俄语
GoCommunity中的#school频道，在
那里发现了
一个有趣的对话 。 通过对话，我对同事如何解释
“域模型”的概念产生了一些想法。
事实证明，这个术语有很多不正确或不太准确，有时甚至是完全不准确的解释，这从根本上扭曲了它。 通过这种对话，本文的思想诞生了。 细节剪下。
有关架构的问题。
因此，开发人员在社区中提出了以下问题：
告诉我如何正确执行架构，比如说我在数据库中制作了一个平板电脑，要求进行改革以为我生成模型，我可以在应用程序中将该模型用作域模型，还是创建自己的域模型并制作一个能够完全为我提供域模型的适配器？根据改革模式创建它？”
另一个程序员对此给出了以下答案：
最简单的是带有贫血模型的架构。 这是DB模型=域模型= API响应模型的时候。 富域模型是一种罕见的野兽，通常退化为贫血。 贫血是指DTO结构。 没有方法的通常的一组属性（字段）。 逻辑退化为在此类dto上运行的一组功能。 福勒有时认为这样的体系结构是反模式的。 但是那是一个很好的微服务解决方案，等等。
读完这篇文章后，我突然意识到为什么围绕业务逻辑层的组织存在如此多的争议，以及为什么许多人未能将诸如
Clean Architecture等方法付诸实践。
“具有贫血模型的体系结构”是什么意思？
如果尝试在网络上找到这样的概念，则很可能找不到它，因为没有这样的体系结构。 这里有一个
“ AnemicDomainModel”的概念，如果我们转到同一个Fowler，事实证明这只是
创建应用程序体系结构的一种
程序方法 （Hello Fortran，ALGOL，COBOL，BASIC，Pascal和C）。 从本质上讲，这就是答案的作者所说的
“带有贫血模型的体系结构” 。
域模型。
接下来，出现下一个问题：
“贫血模型”本质上是一个模型吗？ 我认为不是，这就是原因。
事实是，与
“ DB模型”或
“ API响应模型”不同，域模型不是数据模型。 领域模型
有一个非常具体的定义 。 此外，干扰本质上是
数据模型的数据库模型是错误的。
当涉及领域模型时，这正是概念模型。 这就是主题领域的概念及其之间的关系的整体（即行为和数据的整体）。 通常，将主题领域的一个模型与另一个主题模型区分开的主要特征就是一组业务规则。
是的，概念模型可以使用以不同形式呈现的数据（来自数据库或API响应的数据），但是其本质不会改变，其
行为至关重要 。 我们将输入传递给模型以获得特定的输出。 通过在模型中实现业务逻辑（换句话说，应用业务规则）可以实现此结果。 我在这里找到数学模型和技术过程建模的类比（您好，学生时代）。
概念的替代充满了什么？
当您将数据结构称为
“域模型”时 ，可以自由选择是否替换概念。 这导致一个事实，即业务逻辑经常散布在整个应用程序中。 实际上，在这种情况下，主题区域的模型是使用数据结构运行的非常模糊的一组功能。
在开发中型和大型应用程序的情况下，通常对这些概念的误解或混合会导致在系统开发开始时就已经存在许多问题和疑问，更不用说长期支持了。 例如，其中有以下常见问题：
- “-在哪里验证数据？”
- “-如何避免循环依赖？”
- “-这是一般的“业务逻辑”吗？
- “-我们在哪里保留业务逻辑？”
- 等
而且，如果您有一个简单的CRUD，即 本质上是数据库的接口，很可能不会有问题。 如果要编写基础结构级别的库（例如，用于网络或同一数据库），那么也应该没有问题。 这是因为存在RFC，并且所有“业务规则”早已明确，逻辑也早已明确。 您可以编写一个简单的程序程序，无论如何一切都会很好。
如果我们回到在Go社区中出现有关领域模型的对话这一事实，我会这样说。 由于Go是一种多范式语言并支持许多最成功的OOP概念（组合，接口），因此在对域建模并以过程式方式专门编写代码时不要忽略它们，就像使用BASIC或C一样。
正确解释“域模型”的概念后，很明显为什么通常习惯将业务逻辑分为一个单独的层。 您还将清楚如何选择同一层并实施Clean Architecture或其任何其他变体。 通过隔离一个单独的层，我们实质上创建了一个库，该库以程序代码的形式实现概念模型。 结果，业务逻辑被封装在该库的框架中，并且没有在整个应用程序中扩展（与纯过程方法一样）。
当然，了解这些概念不会使您免于设计错误，不会使您成为理想的开发人员或系统架构师，也不会教您第一次正确地做所有事情。 在这里，不仅理论很重要，实践也很重要。 但是，一旦您正确理解了概念并解释了定义，对于您来说，许多事情将变得更加明显和简单。
总结一下。
- 将“数据”称为域模型是不正确的。
- 域模型是一个既包含行为又包含数据的概念模型。 它可以封装在单独的层中，也可以分布在整个应用程序中。
- “具有贫乏模型的体系结构”无非是一种创建应用程序体系结构的过程方法，其中域模型遍布整个应用程序
注意定义，对它们的研究不仅仅是对角线阅读。 很多时候，我们很懒惰，会零散地获取信息，之后肯定会发生失真。 不要忘记回来记住很长一段时间以来对您似乎很明显的事情，并始终参考来源并称其为锹。
对所有人都好！ 谢谢您的关注。
PS。 我将很高兴听到建设性的批评，以及您对“领域模型”的看法。 欢迎引用源。
UPD：本文并非试图自由解释“域模型”的概念，也不打算将我所知道的一种含义纳入该概念。 我要传达的是：这个概念的含义已经投入了很长时间，并且在有关ComputerScience的书籍和文章中对此进行了详细描述。 本文旨在向同事传达对这些概念的正确认识的重要性，而又不会扭曲其含义（这很重要，因为在实践中，这将使您编写更有意义的代码）。
UPD2：我不是企业理论家架构师。 我和您是同一位实践开发人员。 我每天都会编写代码并谈论这些事情，以使我的代码更好，并使客户更快乐。 如果您认为我本来的意思有误，请共享指向源的链接，并指出我在其中的放置不正确，以便进行修复。
UPD3：因为 许多人以不同的方式解释“学科领域”一词，我举了一些学科领域的例子，以免概念混淆和替代。 主题领域始终取决于您使用应用程序开发解决的问题：
- 预订票（如果您是预订系统的开发人员）
- 银行业务（如果您是银行应用程序开发人员）
- 操作系统（如果您是开发人员OS开发人员）
- 云基础架构管理（如果您是k8s开发人员）
- 虚拟化（如果您是Docker开发人员）
- 性能监控（如果您是Prometheus / Grafana开发人员）