假设我已经列出了我将用来绘制我的领域模型的概念。此外，我有几个用例，我从中做了几个系统序列图。
绘制领域模型时，我不知道从哪里开始：
我做事的顺序无关紧要？我想说可能最好尝试从用例概念进行设计，因为它们通常是您想要使用的，而不是其他类型的概念，虽然有助于很好地描述整个系统，但大部分时间可能当前项目甚至不需要。还有其他我没有考虑的方法吗？你通常如何处理这个问题？
谢谢
无论是否是 DDD，我都建议通过采访产品所有者来确定通用语言 (UL)。以一种让您和产品所有者使用相同语言的方式建立沟通不仅有助于沟通，而且能够以通用术语讨论项目往往有助于领域模型自我定义。
所以，我的回答基本上是讨论、倾听和学习。软件满足需求。从专家的角度理解模型将为应用奠定坚实的基础。
我将首先绘制一个包含所有关系的类图，并根据应用程序的要求仅实现必要的类。
您可以使用贫乏的方法（属性加上 getter 和 setter）来保持简单，并避免在同一步骤中编写业务逻辑的步骤。使用贫血模型，逻辑将进入相应的服务类。这样您以后可以考虑用例。
我知道有些人不喜欢这种做事方式，但它确实有助于维护并避免一些依赖性问题。
下面回答吞噬极乐世界的问题：
就分析而言，从用例（What）开始，然后进入类图（How），这听起来像是一个很好的经验法则。就个人而言，我会在之后制作序列图（何时和谁？），因为您需要知道需要在哪些进程/对象之间发送消息。
除此之外，我认为 UML 只是一种对系统/项目进行建模的方法，而不是一种方法论本身（与 Merise、RAD、RUP、Scrum 等不同）。只要他们有足够的信息来完成它，就没有什么能阻止人们从任何图表开始。事实上，它们应该同时完成，因为每个图表都是同一系统/项目的不同视角。
所以，总而言之，这取决于你如何进行分析。在我的学习过程中，我学会了严格的瀑布方法，在生成一些代码之前，你需要从头到尾进行完整的分析。但是，在实践中情况可能会有所不同，因为当务之急可能是在尽可能短的时间内生成一个工作应用程序。
例如，我最近被介绍到 Scrum 方法论的一个练习，该练习涉及创建一个人们可以发布他们的小说的网站。由于存在时间限制和对应该实现什么的清晰愿景，我们立即开始使用一个简单的类图来表示域模型。然后从我们制作的一系列模拟屏幕中推导出用例。
根据记忆，这些类是 Story、Chapter、User 和 Category。最后一个类已被淘汰，取而代之的是更灵活的 Tag 类。正如您想象的那样，由于应用领域驱动设计和 Java 编程语言的特殊性，现有项目的完整类图会复杂得多。
这种方法可以被视为草率。然而，像这样的网站可以很容易地在几周内使用迭代过程制作出来，并且仍然设计得很好。与瀑布方法相比，迭代过程的优势在于您可以随时调整需求。频繁的需求变化是一个现实，因为人们经常会改变他们的想法，并且可以说在每次迭代之后生成一个工作应用程序的可能性允许人们坚持下去。
当然，当您向客户展示项目时，最好使用 UML 图和一些模拟屏幕进行完整的分析，以便他们了解您提供的内容。这就是 UML 的用武之地。一旦您解释了一些视觉约定，个人应该能够理解这些图表。
最后，如果您正试图确定客户想要什么，那么逐步建立一份可以随身携带的问卷可能是个好主意。采访一个人是您确定应用程序真正需要哪些概念/功能的唯一方法，您应该期望返回以澄清某些方面。另一个提示是当您遇到不熟悉的主题时，在网络上进行一些快速研究。
在您的示例中，这将是通过解剖学的基础知识。除其他外，这将帮助您决定模型应该包含什么以及它应该具有什么粒度（应该考虑哪组器官？它需要有多精确？只需要对器官进行建模还是应该将它们分解成它们的成分，如组织、细胞、化学成分等？）。
我认为从任何感觉合乎逻辑和舒适的地方开始。最好从用例开始，因为它们为您提供明确的方向和目标，并帮助您避免 YAGNI 情况。鉴于您应该尝试开发一个强大的领域模型，这并不重要，因为领域的整体情况很重要。
我想分享我在这种情况下的经验。我通常从编写测试和代码开始。并尝试涵盖端到端的用例。这让我对问题有了足够的了解，最后我也有一些东西可以和我一起工作，我可以向我的客户展示案例。大多数情况下，后续故事都建立在前一个故事的基础上，但我也碰巧后续故事需要对我提出的先前模型进行更改。但这不会影响我，因为我已经有了很好的测试覆盖率。通过这种方式，我提出了适合当前问题的模型，而不是映射现实世界的模型。
您从可以正式化或不正式化的业务需求开始。如果形式化，您将使用用例图。
例如，这里是电子商务应用程序的用例图：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
从这些用例中，你可以很自然地推导出业务实体：产品、产品类别、购物车……即开始准备类图。
这是许多方法中的最佳实践，但这也是常识和自然的。
简短的回答
选择一个用例，画一些协作图（和一个类图）来实现所涉及的领域对象。只关注那些参与以完成用例目标的对象。编写 TDD 测试用例来设定期望值，并逐步为您的领域类建模以满足期望值。 TDD对理解预期行为非常有帮助，它有助于获得更清晰的域模型。您将看到您的领域随着 TDD 的期望而逐渐发展。
长答案
我个人对 DDD 的体验并不容易。那是因为我们一开始就没有必要的基础。我们的团队在不同领域有很多弱点；需求没有被正确捕获，我们只有一个没有真正帮助（没有参与）的客户代表。我们没有适当的发布计划，开发人员缺乏面向对象的概念、最佳原则等。我们遇到的主要问题是花费大量时间来尝试理解域逻辑。我们画了很多类图，但我们从来没有正确地得到领域模型，所以我们停止这样做并找出问题所在。问题是我们太努力去理解领域逻辑，而不是沟通，我们做了假设关于要求。我们决定改变我们的方法，我们应用了 TDD，我们开始编写预期的行为并对领域模型进行编码以满足 TDD 的预期。有时我们在编写 TDD 测试用例时遇到困难，因为我们不了解该领域。我们立即与客户代表交谈，并试图获得更多意见。我们改变了发布策略；应用敏捷方法并经常发布，以便我们从最终用户那里获得真正的反馈。但是，需要确保将最终用户的期望设置在正确的水平。我们根据反馈进行重构，从而使领域模型逐渐演变。随后，我们应用设计模式来提高可重用性和可维护性。我的观点是，单靠 DDD 无法生存，我们必须构建包含该领域的生态系统，开发人员必须具有强大的 OOP 概念，并且必须了解 TDD 和单元测试。我会说 DDD 位于所有 OOP 技术和实践之上。
