在领域模型中使用集合/容器/目录
假设我想为电影院建模。电影院将有几个放映电影的房间（例如 7 个）。
我想知道应该如何设计这种场景的领域模型。
Cinema类概念是否应该与 7 个房间有直接关联？ 替代文本 http://dl.dropbox.com/u/6187267/shooterpics/ nocatalog.jpgCinema类概念是否应该与 7 个房间的目录相关联？ 替代文本 http://dl.dropbox.com/u/6187267/shooterpics/目录.jpg
为什么？
我无法理解为什么在某些地方我看到第一种情况，而在另一些地方我看到类似第二种情况。
如果不是房间，我想描绘电影院和：
- 出售门票（今天）之间的关系。
- 已售出的门票（今天）
- 电影院数据库中的客户
- 电影院指定房间内放映电影的时间集合。
- 您可以在电影院的房间内坐在的一组位置。
我是否应该使用目录，是否应该将它们直接连接到目标中具有多个 * 的 Cinema 概念？
谢谢
Let's say I want to model a cinema. The cinema will have a couple of rooms(for example, 7), where the movies are being played.
I wonder how should I design the domain model for this scenario.
- Should the
Cinemaclass concept concept have a direct association with the 7 rooms?
alt text http://dl.dropbox.com/u/6187267/shooterpics/nocatalog.jpg - Should the
Cinemaclass concept have an association with a catalog of the 7 rooms?
alt text http://dl.dropbox.com/u/6187267/shooterpics/catalog.jpg
Why?
I am having some trouble understanding why in some places I see the first case and in some others I see something like the second case.
If instead of rooms, I wanted to depict the relationship between Cinema and:
- Tickets to sell (today).
- Tickets already sold (today)
- Customers in the Cinema database
- The set of hours at which there are movies playing in a given room in the cinema.
- The set of places you can sit at in a room in the cinema.
Should I use catalogs, should I connect them directly to the Cinema concept with a multiplicity of * in the target?
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
房间目录的作用是什么？
它是否有其他属性/操作，或者它只是充当房间的容器？
您能否预见在 Cinema 实例的生命周期内创建多个与 Cinema 实例关联的房间目录？
房间目录听起来更像是您在服务层而不是域模型中看到的东西。
如果它在结构或行为上没有贡献，那么我可能会剔除它并进行简单的关联。
What is the role of Room Catalog?
Does it have other attributes/operations, or is it only acting as a container for Rooms?
Can you forsee creating multiple Room Catalogs associated with and over the lifetime of the Cinema instances?
Room Catalog kind of sounds to be more like something that you'd see in a the service layer and not in a domain model.
If it's not contributing structurally or behaviorally then I'd probably cull it and go with a simple association.
软件开发行业没有正确的设计或错误的设计。您可以使用第一种或第二种方法（即您可以使用目录或将它们直接连接到影院）。但重要的是，您应该能够证明您的设计的合理性。
There is no correct design or wrong design in the software development industry. You can use either first or second method (i.e. you can use either catalog or connect them directly to the Cinema). But importantly you should be able to justify your design.