从何处开始做域模型？

Question

假设我已经制作了一个概念列表，用于绘制我的域模型。此外，我有几个使用案例，我从中做了几个系统序列图。

当绘制域模型，我从来不知道从哪里开始：

1. 设计模型，因为我相信该系统能。这就是说，如果我为人体建模，我首先要添加心脏，大脑，肠，胃，眼睛，头等的类概念。
2. 从设计用例需要完成的工作开始。这是，如果我有一个用例是有关使人体吞的东西，我会先画了口腔，咽喉，Stomatch，通腑等

中，我做的顺序类概念事情是不相关的？我认为最好从用例概念设计出来，因为它们通常是你想要处理的内容，而不是其他类型的概念，虽然有助于描述整个系统，但很多时候可能会目前的项目甚至不需要。我还没有考虑其他方法吗？你通常如何处理这个问题？

谢谢

Answer 1

我首先绘制一个具有所有关系的类图，并根据您的应用程序的要求仅实现必需的类。

您可以使用贫血的方法（属性加getter和setters）来保持简单并避免在同一步骤中编写业务逻辑的步骤。使用贫血模型时，逻辑将进入相应的Service类。这样你可以稍后考虑用例。

我知道有些人不喜欢这种做事方式，但它确实有助于维护并避免一些依赖性问题。

答到吞噬极乐世界的问题，下面：

在分析方面，从使用情况下（什么），然后继续到类图（如何）听起来像一个很好的经验法则。就个人而言，之后我会做序列图（何时和谁？），因为您需要知道哪些进程/对象消息需要发送。 （除了Merise，RAD，RUP，Scrum等），UML只是模拟系统/项目的一种方式，而不是一种方法。只要有足够的信息来完成任何图表，就没有任何东西阻止某人开始使用任何图表。事实上，它们应该同时完成，因为每个图都是同一个系统/项目的不同视角。

总而言之，这取决于你如何进行分析。在我的学习期间，我学习了刚性瀑布方法，在开始生成一些代码之前，您可以从头到尾做完整的分析。然而，事情在实践中可能会有所不同，因为必须尽可能在最短的时间内生成工作应用程序。

例如，最近我介绍了一个Scrum方法，其中涉及创建一个网站，人们可以发布他们的小说。由于时间有限，并且我们对应该达到的目标有清晰的认识，我们立即开始用骨骼类图来表示domain model。然后从我们制作的一系列模拟屏幕中推导出用例。

从内存中，类是故事，章节，用户和类别。最后一节课被淘汰，以支持更灵活的Tag类。正如您想象的那样，由于应用了领域驱动设计和Java编程语言的特性，现有项目的完整类图将会更加复杂。

这种方法可能被视为马虎。然而，像这样的网站可以使用迭代过程在几周内轻松完成，并且仍然设计得很好。迭代过程优于瀑布方法的优点是您可以随时随地调整需求。频繁的需求变化是一个现实，因为人们经常会改变主意，并且在每次迭代后都可以生成一个工作应用程序，从而让人们可以继续讲课。

当然，当您向客户展示项目时，使用UML图表和一些模拟屏幕进行完整的分析将是更可取的，因此他们可以了解您提供的内容。这就是UML的用途。一旦你解释了一些可视化约定，一个人应该能够理解这些图表。

最后，如果您处于您想要确定客户需求的情况下，逐步建立您可以随身携带的调查问卷可能是一个好主意。采访一个人是唯一可以确定应用程序真正需要哪些概念/功能的方法，并且您应该回过头来澄清某些方面。另一个提示是当你遇到你不熟悉的主题时，在网上做一些快速的研究。

在你的例子中，这将是通过解剖学的基础知识。除此之外，这将帮助你决定模型应该包含什么以及它应该具有什么粒度（应该考虑哪一组器官？它需要多精确？只有器官需要建模或者应该分解成他们的成分如组织，细胞，化学成分等？）。

Answer 2

我觉得开始的地方会是任何合乎逻辑和舒适的地方。最好从用例开始，因为它们给你明确的方向和目标，并帮助你避免YAGNI的情况。鉴于您应该尝试开发一个强大的领域模型，因为整个领域的情况非常重要，所以这并不重要。

Answer 3

无论是否DDD，我都会建议通过访问产品所有者来确定无处不在的语言（UL）。以一种让你和产品拥有者说同一种语言的方式建立沟通不仅是沟通的助手，而且能够用通常的术语讨论项目往往有助于领域模型定义自己。

所以，我的答案基本上是讨论，倾听和学习。软件满足需求。从专家的角度理解模型将为应用奠定坚实的基础。

Answer 4

我想分享我在这种情况下的经验。我通常从编写测试和代码开始。并尝试涵盖一个端到端的用例。这给了我足够的关于问题的想法，最后我还有一些与我合作的东西，我可以向我的客户展示案例。大多数时候，后续故事都是建立在前一个故事的基础之上，但是后来的故事也需要在前一个模型中进行更改。但这并不影响我，因为我已经有了很好的测试覆盖率。通过这种方式，我提出了适合当前问题的模型，而不是映射现实世界的模型。

Answer 5

您从可以正式化或不正式的业务需求开始。如果形式化，你会使用用例图。

例如这里是一个电子商务应用用例图： http://askuml.com/blog/e-commerce/

http://askuml.com/files/2010/07/e-commerce-use-case.jpg http://askuml.com/files/2010/07/e-commerce-use-case2b.jpg

从这些用例，你自然可以推断出实体企业：产品，产品类别，购物车，...开始准备班级图表。

这是许多方法中的最佳实践，但这也只是常识和自然。

Answer 6

短的答案

选择一个用例，得出了一些协作图（和类图）来实现所涉及的域对象。只集中于那些为了完成用例目标而参与的对象。编写TDD测试用例来设置期望值，并逐渐为您的域类建模以满足期望。 TDD对理解预期行为非常有帮助，并有助于获得更清晰的域模型。您将看到您的域名随着TDD的期望而逐渐演变。

龙答案

我与DDD个人的经验是不容易的。那是因为我们首先没有必要的基金会。我们的团队在不同领域有很多薄弱环节;要求没有得到妥善处理，我们只有一位客户代表，他没有真正帮助（不参与）。我们没有适当的发布计划，开发人员缺乏面向对象的概念，最佳原则等等。我们遇到的主要问题是花费了太多时间来试图理解域逻辑。我们勾画了许多类图，并且我们从来没有正确的领域模型，所以我们停止了这样做，并发现出了什么问题。问题在于我们太过努力去理解领域逻辑，而不是沟通我们根据需求制定了假设。我们决定改变我们的方法，我们应用了TDD，我们开始编写预期行为并编写域模型以满足TDD的期望。有时候我们因为不理解域而被写入TDD测试用例。我们马上和客户代表交谈，并试图获得更多的意见。我们改变了发布策略;应用敏捷方法并经常发布，以便我们从最终用户那里得到真正的反馈。但是，需要确保最终用户的期望值设定在正确的水平。我们根据反馈进行重构，并以这种方式逐渐演变出领域模型。随后，我们应用设计模式来提高可重用性和可维护性。我的观点是DDD本身无法生存，我们必须建立一个包含领域的生态系统，开发者必须拥有强大的面向对象的概念，并且必须欣赏TDD和单元测试。我会说DDD位于所有OOP技术和实践之上。