进行领域模型时从哪里开始？
假设我已经列出了将用来绘制领域模型的概念列表。此外，我有几个用例，从中我绘制了几个系统序列图。
在绘制领域模型时，我永远不知道从哪里开始：
- 按照我认为的系统设计模型。也就是说，如果我要对人体进行建模，我首先添加心脏、大脑、肠、胃、眼睛、头部等类概念。
- 首先设计用例需要完成的任务。也就是说，如果我有一个关于让人体吞咽某些东西的用例，我会首先绘制“嘴”、“喉咙”、“胃”、“肠”等的类概念。
我做事的顺序无关紧要？我想说可能最好尝试从用例概念进行设计，因为它们通常是您想要使用的概念，而不是其他类型的概念，尽管它们有助于很好地描述整个系统，但大多数时候可能会当前项目甚至不需要。还有其他我没有考虑的方法吗？您通常如何处理这个问题？
谢谢
Let's say I've made a list of concepts I'll use to draw my Domain Model. Furthermore, I have a couple of Use Cases from which I did a couple of System Sequence Diagrams.
When drawing the Domain Model, I never know where to start from:
- Designing the model as I believe the system to be. This is, if I am modelling a the human body, I start by adding the class concepts of Heart, Brain, Bowels, Stomach, Eyes, Head, etc.
- Start by designing what the Use Cases need to get done. This is, if I have a Use Case which is about making the human body swallow something, I'd first draw the class concepts for Mouth, Throat, Stomatch, Bowels, etc.
The order in which I do things is irrelevant? I'd say probably it'd be best to try to design from the Use Case concepts, as they are generally what you want to work with, not other kind of concepts that although help describe the whole system well, much of the time might not even be needed for the current project. Is there any other approach that I am not taking in consideration here? How do you usually approach this?
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
无论是否 DDD，我都建议通过采访产品负责人来确定通用语言 (UL)。以一种让您和产品所有者使用相同语言的方式建立沟通不仅有助于沟通，而且能够用通用术语讨论项目往往有助于领域模型定义自身。
所以，我的回答基本上是讨论、倾听和学习。软件满足需求。从专家的角度理解模型将为应用奠定坚实的基础。
Whether DDD, or not, I would recommend with determining the ubiquitous language (UL) by interviewing the product owner(s). Establishing communication in a way that will have you and the product owners speaking the same language not only aides in communication, but being able to discuss the project in common terms tends to help the domain model define itself.
So, my answer is basically to discuss, listen, and learn. Software serves a need. Understanding the model from the viewpoint of the experts will lay the solid groundwork for the application.
我首先绘制一个包含所有关系的类图，并根据应用程序的要求仅实现必需的类。
您可以使用贫乏的方法（属性加上 getter 和 setter）来使事情变得简单，并避免在同一步骤中编写业务逻辑的步骤。对于贫血模型，逻辑将进入相应的服务类。这样您就可以稍后考虑用例。
我知道有些人不喜欢这种做事方式，但它确实有助于维护并避免一些依赖性问题。
回答下面的 devored elysium 问题：
就分析而言，从用例（什么）开始，然后继续到类图（如何）听起来是一个很好的经验法则。就个人而言，我会在之后绘制序列图（何时和谁？），因为您需要知道需要在哪些进程/对象之间发送消息。
除此之外，我的看法是，UML 只是一种对系统/项目进行建模的方法，而不是其本身的方法（与 Merise、RAD、RUP、Scrum 等不同）。只要有足够的信息来完成图表，就没有什么可以阻止人们从任何图表开始。事实上，它们应该同时完成，因为每个图都是同一系统/项目的不同视角。
因此，总而言之，这取决于您如何进行分析。在学习期间，我学习了严格的瀑布方法，在生成一些代码之前从头到尾进行完整的分析。然而，在实践中情况可能有所不同，因为当务之急可能是在尽可能短的时间内生成一个可用的应用程序。
例如，我最近在一次涉及创建一个网站的练习中接触到了 Scrum 方法，人们可以在其中发布他们的小说。由于时间有限并且对应该实现的目标有清晰的愿景，我们立即从一个简单的类图开始来表示 域模型。然后从我们制作的一系列模拟屏幕中推断出用例。
根据记忆，这些类是故事、章节、用户和类别。最后一个类已被淘汰，取而代之的是更灵活的 Tag 类。正如您所想象的那样，由于应用领域驱动设计和 Java 编程语言的特殊性，现有项目的完整类图将会复杂得多。
这种方法可能被视为草率。然而，像这样的网站可以通过迭代过程在几周内轻松制作完成，并且仍然设计得很好。迭代过程相对于瀑布方法的优点是您可以不断调整需求。频繁的需求变化是一个现实，因为人们经常会改变他们的想法，并且在每次迭代之后生成一个工作应用程序的可能性可以让人们保持在正确的轨道上。
当然，当您向客户展示项目时，最好使用 UML 图和一些模拟屏幕进行完整分析，以便他们了解您所提供的内容。这就是 UML 的用武之地。一旦您解释了一些视觉约定，个人就应该能够理解这些图表。
最后，如果您正试图确定客户的需求，那么逐步建立一份可以随身携带的调查问卷可能是个好主意。采访一个人是您确定应用程序真正需要哪些概念/功能的唯一方法，并且您应该期望回去以澄清某些方面。另一个技巧是当您遇到不熟悉的主题时，在网上进行一些快速研究。
在您的示例中，这将是了解解剖学的基础知识。除其他外，这将帮助您决定模型应包含什么内容以及它应具有什么粒度（应考虑哪组器官？需要多精确？是否只需要对器官进行建模，还是应该将它们分解为它们的成分如组织、细胞、化学成分等？）。
I'd start by a drawing a class diagram with all the relationships and implement only the classes that are necessary according to the requirements of your application.
You can use an anemic approach (attributes plus getters and setters) to keep things simple and avoid the step of writing business logic in the same step. With an anemic model, the logic would go into a corresponding Service class. That way you can consider Use Cases later on.
I know some people don't appreciate this way of doing things but it does help with maintenance and avoids some dependency issues.
Answer to devoured elysium's question below:
In terms of analysis, starting with Use cases (What) and then proceeding to the class diagram (How) sounds like a good rule of thumb. Personally, I'd do the Sequence diagram (When and Who?) afterwards, as you'd need to know between which processes/objects messages need to be sent.
Beyond that my take on things is that UML is simply a way to model a system/project and not a methodology by itself (unlike Merise, RAD, RUP, Scrum, etc.). There is nothing stopping someone starting off with any diagram as long as they have the sufficient information to complete it. In fact, they should be done simultaneously since each of the diagrams is a different perspective of the same system/project.
So, all in all it depends on how you go about the analysis. During my studies I was taught the rigid waterfall approach, where you do a complete analysis from start to finish before producing some code. However, things can be different in practice, as the imperative might be to produce a working application in the least time possible.
For example, I was introduced to the Scrum methodology recently for an exercise involving the creation of a web site where people can post their fictions. As there was a time constraint and a clear vision of what should be achieved, we started right away with a bare bones class diagram to represent the domain model. The Use cases were then deduced from a series of mock screens we'd produced.
From memory, the classes were Story, Chapter, User and Category. This last class was phased out in favour of a more flexible Tag class. As you'd imagine, the complete class diagram of the existing project would be much more complex due to applying domain driven design and the specificities of the Java programming language.
This approach could be viewed as sloppy. However, a web site like this could easily be made in a couple of weeks using an iterative process and still be well designed. The advantage an iterative process has over the waterfall approach is that you can continually adjust requirements as you go. Frequent requirements changing is a reality, as people will often change their minds and the possibility of producing a working application after each iteration allows one to stay on course so to speak.
Of course, when you're presenting a project to a client, a complete analysis with UML diagrams and some mock screens would be preferable so they have an idea of what you're offering. This is where the UML comes in. Once you've explained some of the visual conventions, an individual should be able to understand the diagrams.
To finish off, if you're in the situation where you're trying to determine what a client wants, it's probably a good idea to gradually build up a questionnaire you can bring with you. Interviewing a person is the only way you can determine what concepts/features are really needed for an application, and you should expect to go back in order to clarify certain aspects. Another tip would be to do some quick research on the web when you're confronted with a subject matter you're unfamiliar with.
In your example, this would be to go through the basics of anatomy. Among other things, this will help you decide what the model should contain and what granularity it should have (What group of organs should be considered? How precise does it need to be? Do only the organs need to modeled or should they be decomposed into their constituents like tissues, cells, chemical composition, etc. ?).
我认为从任何感觉合乎逻辑且舒适的地方开始。最好从用例开始，因为它们为您提供明确的方向和目标，并帮助您避免 YAGNI 情况。鉴于您应该尝试开发一个强大的领域模型，这并不重要，因为领域的整体情况很重要。
I think the place to start would be whatever feels logical and comfortable. It's probably best to start with the use cases, as they give you clear direction and goals, and help you avoid YAGNI situations. Given that you should be trying to develop a strong domain model, it shouldn't really matter, as the whole picture of the domain is important.
我想分享我对此类情况的经验。我通常从编写测试和代码开始。并尝试涵盖一个端到端的用例。这让我对问题有足够的了解，最后我还有一些与我合作的东西，我可以向我的客户展示案例。大多数情况下，后续故事都是建立在前一个故事之上的，但我也碰巧后续故事需要对我提出的先前模型进行更改。但这不会影响我，因为我已经有了很好的测试覆盖率。通过这种方式，我提出了适合当前问题的模型，而不是映射现实世界的模型。
I would like to share my experience for such type of situations. I usually start with writing tests and code. And try to cover one end to end use case. This gives me fair enough idea about problem and at the end I also have something working with me which I can show case to my client. Most of the time subsequent stories build on top of previous one, but it also happens to me that subsequent stories require changes in the previous model I came up with. But this does not impact me as I already have good test coverage. In this way I came up with the model which fits for the current problem, not the model which maps the real world.
您从可以正式化或非正式化的业务需求开始。如果形式化，您将使用用例图。
例如，以下是电子商务应用程序的用例图：
http://askuml.com/blog/e-commerce/
http://askuml.com/files/2010/07/e-commerce-use -案例.jpg
http://askuml.com/files/2010/07/ e-commerce-use-case2b.jpg
从这些用例中，您可以自然地推断出业务实体：产品、产品类别、购物车……那就开始准备类图。
这是许多方法中的最佳实践，但这也是常识和自然的。
You start with Business Requirements which can be formalized or not. If formalized you would use Use Case Diagrams.
For example here are use case diagrams for an e-commerce app:
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
From these use cases, you can naturally deduce the business entities: product, category of product, shopping cart, ... that is start to prepare class diagrams.
This is best practice in many methodologies but this is also just common sense and natural.
简答
选择一个用例，绘制一些协作图（和类图）来实现所涉及的领域对象。仅关注那些参与以实现用例目标的对象。编写 TDD 测试用例来设置期望，并逐步对域类进行建模以满足期望。 TDD 对于理解预期行为非常有帮助，并且有助于获得更清晰的领域模型。您将看到您的领域随着 TDD 期望逐渐发展。
长答案
我个人在 DDD 方面的经历并不容易。因为我们本来就没有必要的基础。我们的团队在不同领域有很多弱点；需求没有被正确捕获，我们只有一位客户代表，但他并没有真正提供帮助（没有参与）。我们没有合适的发布计划，开发人员缺乏面向对象的概念、最佳原则等。我们遇到的主要问题是花费大量时间来尝试理解领域逻辑。我们绘制了许多类图，但从未获得正确的领域模型，因此我们停止这样做并找出问题所在。问题在于我们过于努力地试图理解领域逻辑，而不是进行沟通，而是对需求做出了假设。我们决定改变我们的方法，我们应用了 TDD，我们开始编写预期的行为并对领域模型进行编码以满足 TDD 的期望。有时我们在编写 TDD 测试用例时陷入困境，因为我们不了解该领域。我们立即与客户代表交谈并试图获得更多意见。我们改变了发布策略；应用敏捷方法并频繁发布，以便我们从最终用户那里得到真实的反馈。然而，需要确保最终用户的期望设定在正确的水平。我们根据反馈进行重构，领域模型就这样逐渐演化。随后，我们应用设计模式来提高可重用性和可维护性。我在这里的观点是，仅靠 DDD 是无法生存的，我们必须构建拥抱领域的生态系统，开发人员必须具有强大的 OOP 概念，并且必须欣赏 TDD 和单元测试。我想说 DDD 位于所有 OOP 技术和实践之上。
Short answer
Pick a use case, draw some collaboration diagram (and a class diagram) to realize the domain objects involved. Concentrate only on those objects participated in order to accomplish use case goal. Write TDD test case to set the expectation and gradually model your domain classes to meet the expectations. TDD is very helpful to understand the expected behaviors and it helps to get the cleaner domain model. You will see your domain evolve gradually along with the TDD expectations.
Long answer
My personal experience with DDD was not easy. That was because we didn't have necessary foundations in the first place. Our team had many weak points in different areas; requirements were not captured properly and we only had a customer representative who was not really helpful (not involved). We didn't have a proper release plan and developers had a lack of Object Oriented concepts, best principles and so on. The major problem we had was spending so much time on trying to understand the domain logic. We sketched many class diagrams and we never got the domain model right, so we stopped doing that and found out what went wrong. The problem was that we tried too hard to understand the domain logic and instead of communicating we made assumptions on the requirements. We decided to change our approach, we applied TDD, we started writing the expected behavior and coded the domain model to meet the TDD's expectations. Sometimes we got stuck writing TDD test cases because we didn't understand the domain. We straight away talked to the customer representative and tried to get more input. We changed our release strategy; applied agile methodology and release frequently so that we got real feedback from the end user. However, needed to ensure the end user expectation was set at the right level. We refactored based on the feedback, and in that way the domain model evolved gradually. Subsequently, we applied design patterns to improve reusability and maintainability. My point here is that DDD alone cannot survive, we have to build the ecosystem that embraces the domain, developers must have strong OOP concepts and must appreciate TDD and unit test. I would say DDD sits on top of all the OOP techniques and practices.