因此,我想得到一些关于如何对业务逻辑域进行适当建模的建议。
在不涉及太多NDA信息的情况下,我试图建立一个包含项目和人员的相对较大的系统模型(到目前为止没有太可怕)。现在,我正在Rails中构建它,只是为了让一些东西快速走出家门,但最终我将把它切换到一个Ember.js/JSON应用程序(这对这个问题并不重要)。
因此,这个系统有几种不同类型的“人”--有“用户”(实际上可以登录到系统的人)和“联系人”(关于人们的信息,如电话号码、地址、电子邮件等)。这两者分开的唯一原因是它们在逻辑上是不同的(登录不需要联系人信息,也不是每个“联系人”都需要登录信息或应该能够登录)。一个直接的问题是,让这两个实体分开是否有意义,或者我是否应该制作一个宽而平坦的对象,用所有字段来建模登录(我正在考虑所有设计在这里添加的字段)和所有字段来创建联系人信息。
此外,还有一些项目。项目有不同能力的人作为“联系人”;一个项目可能有“弗雷德”作为领导或经理,“戴安娜”作为客户。另一个项目有可能(虽然不太可能)以“戴安娜”为主导,“弗雷德”作为另一个角色。关键是每个接触在每个项目中所扮演的角色是不稳定的。要使项目有效(不一定有效,但必须是活动的),必须填充一些角色。
最后,作为一个转折,该应用程序是多租户。因此,系统本身有多个拥有自己客户的“客户”(因为没有更好的术语),所有(顶级)客户数据必须严格分区。
现在,我要做的是:
所以,我会把它放在这里,并以我开始的话结束:有人有任何关于如何正确建模这个系统的建议或建议吗?我甚至会回答“哥们儿,这是一个复杂的系统,但你已经尽力了。”:)
谢谢!
发布于 2014-07-02 15:36:19
我会这样处理它..。
首先,图表就是一切!也许您已经这样做了,也可能没有,但我总是创建一个图表,显示所有不同的参与者(在本例中,用户、联系人、客户和客户)并绘制他们的关系。
第二,我不会把用户和联系人分开。如果联系人变成了用户怎么办?如果用户跌落到联系人那里怎么办?等等,这些都是你必须问自己的问题--那些“什么-如果”的场景,虽然现在看起来不太可能,但可能会在稍后出现。如果用例发生变化,您将希望您的系统尽可能灵活。
因此,我会创建一个"user“表,并给他们一个特权列。这个人是用户还是联系人?如果该人是用户,则不需要联系人信息,但如果他们是联系人,则该联系人是必需的,但他们无法登录。另外,如果此人既是用户又是联系人,您可能还有另一种选择。
然后,我将有一个单独的“关系”表,为多到多用例的客户到客户的客户。类似于:
| ID | UserID | CustomerID |
-----------------------------
| 1 | 2 | 3 |
| 2 | 2 | 4 |
| 3 | 2 | 5 |
| 4 | 7 | 6 |
如果UserID是父客户的ID,CustomerID是子客户的ID,那么您就可以限制谁看到了什么。
对于您的项目问题,同样的事情,我将创建一个单独的模型/表,名为ProjectRoles,它具有项目ID、用户ID和角色名称。这是一个很好的平衡,确保表的设置是坚实的/持久的,而且还能快速加载查询。我宁愿第一次是对的!
https://stackoverflow.com/questions/24534797
复制相似问题