问题标签 [domain-data-modelling]

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

0 投票
2 回答
388 浏览

c# - 在此领域数据建模场景中访问参考数据的正确方法是什么?

初始警告:很长的帖子,无论如何我可能完全错误地理解了模式:

给定以下类,它是客户聚合的开始:

CustomerType 由一个值对象表示:

当我有一个带有 CustomerTypeId 的客户对象时,这一切都很好。但是,当我想在我的 MVC 视图中填充 DropDownList 时,我正在努力解决如何从 ICustomerTypeRepostory 正确获取 CustomerType 值列表的概念。

ICustomerTypeRepository非常简单:

基本上,我想要的是能够ICustomerTypeRepository从我的控制器正确调用,但是我认为最好将 DAL(存储库)层与控制器分开。现在,我只是把事情复杂化了吗?

这就是我的控制器当前的状态:

这对我来说似乎是错误的,因为我在 Controller 和 Customer 中有存储库。对我来说,应该有一个用于 CustomerType 的隔离访问层,这似乎是合乎逻辑的。即CustomerType.GetList()

那么,我应该通过哪种方式将CustomerType对象暴露ICustomerTypeRepositoryCustomerController?

0 投票
3 回答
350 浏览

asp.net-mvc - ASP.Net MVC - 这个实体层是不是太过分了?

我有一个域数据模型,它返回如下类:

当将此数据传递回我的网格时,我已经读过最好始终以扁平格式将数据返回到视图。所以我有以下代表网格行的类:

所以,当它被渲染时,我只是调用Model.Weapon,而不是Model.FatalHit.Weapon。它确实使视图的代码更易于阅读,但由于需要映射,它显然是额外的工作层。

这真的是一种很好的工作方式,还是只是浪费时间?

0 投票
1 回答
286 浏览

c#-4.0 - 这是从域模型中实例化具有依赖关系的对象的正确方法吗?

我试图避免以贫乏的域模型结束,所以我试图在域模型本身中保留尽可能多的逻辑。我有一个名为 的方法AddIngredient,它需要KeyedObject向我的Recipe聚合中添加一个新方法。

由于域模型本身意味着没有存储库,因此我通过业务规则类获取成分:

如您所见,我正在使用一条线ServiceLocator.Factory.Resolve<GetIngredient>();来获取我的GetIngredient业务规则类。GetIngredient是一个简单的命令处理程序,如下所示:

我将我的 IoC 工厂类分配给ServiceLocator.Factory,因此 Domain 可以使用自己的接口,而无需查看具体的类实现:

我很确定我做错了什么,因为这一切都感觉有点像笨蛋。

  • 谁能发现任何明显的错误?
  • 是否有更合适的方法来实例化业务规则处理程序,例如GetIngredient没有对我的 IoC 工厂的静态引用?
0 投票
1 回答
237 浏览

visual-studio-2010 - VisualStudio 架构建模 - 如何导出为图像?

我生成了一个非常大的模型,需要将其放入技术文档中。它不适合超过 8000 个节点和超过 32000 个链接。

我试过截图工具,但它们只做垂直滚动,而不是水平和垂直滚动来获得整个区域。

我还保存为 XPS 并在 IE 中打开,然后导出到 OneNote,但分辨率丢失并且节点不可读。

有人对我如何将这个巨大的模型变成图像有任何建议吗?

如果在查看模型时启用了“文件”>“打印”菜单,我可以打印到 PDF 或打印到图像。

编辑:

4年后,我仍然遇到这个!这次使用的是 TIBCO 模型,但与上次相比,这是 TINY可能小 200 倍

在此处输入图像描述

0 投票
1 回答
589 浏览

domain-driven-design - 党的角色和有限的上下文

我正在尝试使用 Java Modeling in Color 中的Party Place ThingRole原型。

此外,我还尝试合并 DDD 最佳实践,现在假设我们有 1 个人在我的应用程序中扮演 2 个角色,比如客户和患者。

客户角色用于 CRM 有界上下文,患者角色用于医院管理有界上下文。

我的角色类可以使用弱 id 访问 Person 详细信息,这是一个可以唯一表示 Person 的值对象,可以在此处找到此方法的详细信息。

现在,在 Party Place Thing 原型中,指定的职责之一是能够列出派对所扮演的角色。

鉴于角色存在于不同的限界上下文中,如何实现这一点?

因此,理想情况下,客户和患者不应与 Person 存在于相同的有界上下文中

0 投票
3 回答
655 浏览

c# - 交易:如何声明`Indicator`接口

我试图在“量化金融”上问这个问题,但似乎这是一个更好的地方,因为这个问题更多的是关于编程而不是交易

你如何声明Indicator接口?建模“指标”的正确方法是什么?

我正在使用 c#,我想声明这样的Indicator接口:

甚至可能像这样:

我认为“纯价格”也是微不足道的指标:

MA的例子:

你怎么看?欢迎任何建议!

0 投票
1 回答
99 浏览

domain-driven-design - 创建域设计模型的最佳方法?

更新:

我正在寻找的是我应该分别创建每个类而不是在类中添加 getter/setter 属性,我的意思是:

所以为了创建一个访问,我应该在 VISIT 中有以下道具

或者我应该有这个:

结束更新

如果我要朝着正确的方向前进,我需要建议/反馈,下面是域模型(不是整个项目的一部分)。

我在该访问模型中有一个名为“访问”的课程,我将有基本的访问,如姓名、目的、开始、结束日期等……在那个课程中,我还有谁将主持访问以及谁请求访问。

你觉得下面的课怎么样?

在此处输入图像描述

}

0 投票
1 回答
467 浏览

scala - 是否有支持 Scala 配置文件的可视化建模工具/语言或样式?

[目前在 SO 上活跃的类似问题是“函数式编程范式是否有可视化建模语言或风格? ”这与这个问题不同,因为另一个问题只关注函数式编程范式,而我的问题是寻找一种建模工具支持面向对象范式(它独立拥有许多完善的可视化建模 UML 工具)和函数式编程范式的组合。

是否有支持 Scala 配置文件(提供并包含所有 Scala 语言工件)的可视化建模工具/语言或样式,或者可以说它同时支持面向对象的编程范式函数式编程范式

对于企业规模的 Scala 项目,使用什么建模工具 - 业务分析师为逻辑(概念)视图和开发视图准备可视模型或任何其他类型的模型?

  • 逻辑视图与系统提供给最终用户的功能有关。
  • 开发视图从程序员的角度说明了一个系统,并关注软件管理。

在软件开发的某些圈子中,正式建模是一项要求,无论您认为这是多么官僚。不同团队对项目的完成有多个级别的参与,许多参与的人对代码一无所知。他们不需要,如果被问到这将是一个很大的麻烦。正式的建模是为了确保他们能够更好地了解事物的工作方式,以便他们能够在开发中发挥自己的作用。(本段摘自:https ://stackoverflow.com/users/166802/codnik )

0 投票
1 回答
635 浏览

domain-driven-design - Instantiating objects - Polymorphism

I have a financial application that processes 'bonds'. I need to

  1. Model the application to avoid an anaemic model (which i understand is bad).
  2. Instantiate different implementations depending on the type of bond.

The system gets instructions from an external system, and applies the instructions to the specified bond. hence i have an Instruction entity

e.g. of an instruction to vote 'yes' for a resolution passed on the bond

and a Bond entity

However, an instruction usually does more than just one thing (it is effectively many instructions in one), e.g. an instruction to cancel a previous instruction, that would mean, firstly, it cancels a previous transaction, then certain values need to be recalculated. Also, a single instruction can come overloaded, it can be to cancel a previous instruction as well as vote for a resolution.

I have been advised to use a domain service to process a new instruction.

The problem i see with this structure is that for each instruction, all methods are called even if the method is not relevant. I could use some if statements but then the code would look untidy.

Now my question is,

  1. Is this the best way to model?
  2. And for the calculation, depending on the bond type the calculation differs. So i want to implement polymorphism. I have been told that i need to use a factory to instantiate the correct implementation. Is this the best approach?

For BondType 1,3,5 i use calculationA, for bondType 2,7... i need to use Calculation B. how do i INSTANTIATE the different calc types??? NB, i am well versed with polymorphism, however, i have been unable to find solid examples of how to instantiate the correct implementation. thnx for reading this far...

0 投票
1 回答
442 浏览

php - 领域模型关联延迟加载

我目前面临处理聚合实体之间的关联的问题。

考虑以下示例:

现在,我们有一个 ,,User" 实体,这也是我的聚合根。他可以有一个与之关联的 ,,Product" 和许多 ,,Aliases"。我目前需要的是检索相关的能力,,Product" 和 ,,Aliases" 在域模型中按需创建。用户由 UserFactory 创建,可以单独使用,也可以在从持久化数据创建实体时在 UserRepository 中使用。

这样做的原因是因为我们的业务逻辑(如您在示例中看到的)很大程度上依赖于对象之间的关联,我认为与对象之间的关联相关的逻辑应该在领域模型中完成(或者这应该被移出? )

我考虑了以下解决方案:

1)在构造用户时只需加载所有内容(相关的 Product 和 Aliases )。

优点:

  • 作品?

缺点:

  • 大的性能问题(不幸的是,我正在开发实时高负载系统,所以这不能被忽略)

2)将关系存储库注入到领域模型中

}

优点:

  • 工作..

缺点:

  • 击败(imo) DDD 的目的,要求用户在内部拥有存储库(因此域模型与持久性相耦合..)

3)将关联相关的逻辑委托给域模型(可能是域服务和策略?)

优点:

  • 也有效

缺点:

  • 实际上我觉得这会导致贫血的领域模型,因为我们的大部分业务逻辑都是基于对象的关系,所以很多代码会从领域对象中移出,这没有任何意义。

4)创建一个专门的关系对象来处理关系:

优点:

  • 也有效

缺点:

  • 循环依赖( User 需要在里面拥有 UserProductRelationship 并依赖它。UserProductRelationship 需要与 User 实体一起提供。结合这两个类将导致场景 #2 )。

也许我没有正确理解某些东西..如果有人有建议,我很乐意听到。

谢谢!