在做域模型时从哪里开始？

Question

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

在绘制域模型时，我永远不知道从哪里开始：

1. 设计模型，因为我相信系统。 这就是说，如果我在模拟人体，我首先要添加心脏，脑，肠，胃，眼睛，头等的类概念。
2. 首先设计用例需要完成的工作。 这就是说，如果我有一个关于让人体吞下一些东西的用例，我首先要画出口，喉咙，Stomatch，肠等的课堂概念。

我做事的顺序无关紧要？ 我想说最好尝试从Use Case概念设计，因为它们通常是你想要使用的，而不是其他类型的概念虽然有助于描述整个系统，但很多时候可能当前项目甚至都不需要。 我还没有考虑其他任何方法吗？ 你通常如何处理这个问题？

谢谢

Answer 1

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

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

Answer 2

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

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

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

回答吞食极乐世界的问题如下 ：

在分析方面，从用例（What）开始，然后继续到类图（How）听起来像一个好的经验法则。 就个人而言，我之后会做序列图（何时和谁？），因为您需要知道需要发送哪些进程/对象消息。

除此之外，我对事物的看法是，UML只是一种模拟系统/项目的方式，而不是一种方法本身（不像Merise，RAD，RUP，Scrum等）。 只要有足够的信息来完成它，就没有什么能阻止某人从任何图表开始。 事实上，它们应该同时完成，因为每个图表都是同一系统/项目的不同视角。

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

例如，最近我被介绍了Scrum方法，用于创建一个人们可以发布他们的小说的网站。 由于存在时间限制和对应该实现的目标的清晰视野，我们立即开始使用裸骨类图来表示域模型 。 然后从我们制作的一系列模拟屏幕中推断出用例。

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

这种方法可以被视为草率。 但是，像这样的网站可以使用迭代过程在几周内轻松制作，并且仍然设计得很好。 迭代过程相对于瀑布方法的优势在于，您可以随时随地调整需求。 频繁的需求变化已经成为现实，因为人们经常会改变他们的想法，并且在每次迭代之后生成工作应用程序的可能性允许人们保持在路线上可以这么说。

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

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

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

Answer 3

我认为，开始的地方将是任何合乎逻辑和舒适的地方。 最好从用例开始，因为它们为您提供明确的方向和目标，并帮助您避免YAGNI情况。 鉴于您应该尝试开发一个强大的域模型，它应该不重要，因为域的整个画面很重要。

Answer 4

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

Answer 5

您从业务需求开始，可以正式化或不正式化。 如果形式化，您将使用Use Case Diagrams。

例如，这里是电子商务应用程序的用例图： 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无法生存，我们必须构建包含域的生态系统，开发人员必须拥有强大的OOP概念，并且必须欣赏TDD和单元测试。 我会说DDD是所有OOP技术和实践的基础。