When you’re creating your domain model, a good source of domain classes includes the highlevel requirements—the ones that are usually (but not always) written in the form “The system shall do this; the system shall not do that.” It’s useful to scan these requirements, extracting the nouns and noun phrases. You can then refine these to create the initial domain model.
Опишите требования к системе в виде "Система должна делать это", "Система не должна делать это". Иными словами, опишите бизнес-функции проектируемого приложения. Этот документ может использоваться как источник для формирования начального состава предметной области и прецедентов.
При рефакторинге существующей системы вы можете записать сценарий действия пользователей с существующей системой и точно так же использовать данный сценарий как источник для первичного выделения сущностей.
When creating a domain model, be sure to focus on real-world objects within the problem domain. Try to organize your software architecture around what the real world looks like. The real world tends to change less frequently than software requirements.
Over time, you’ll flesh out your domain model with new domain classes, as and when you identify them. You’ll also notice relationships (or associations) between them—for example, a Book Review belongs to a Book, and a Purchase Order and Credit Card are two of a kind, as they’re both Payment Types.
The first relationship (Book Review belongs to a Book) is called aggregation (has-a,because a Book has a Book Review). The second relationship (Purchase Order and Credit Card are both Payment Types) is called generalization (is-a, because a Purchase Order is a Payment Type)
Начните моделирование предметной области с выделения сущностей реального мира. Объекты реального мира меняются гораздо реже, чем требования к программному обеспечению.
После идентификации сущностей в заметите взаимосвязи между ними. Основными типами связи являются агрегирование и генерализация. Отношение агрегирования применяется в случаях, когда одна сущность включает одну или несколько вложенных сущностей (Автомобиль содержит колеса). Отношение генерализация применяется когда одна сущность является частным случаем другой (Евразия это Материк).
If ambiguous requirements are the enemy, the domain model is the first line of defense. Ambiguous usage of names by “subject matter experts” is very common and very harmful. The domain model should serve as a project glossary that helps to ensure consistent usage of terms when describing the problem space.
Using the domain model as a project glossary is the first step toward disambiguating your model. In every Jumpstart workshop that Doug teaches, he finds at least two or three domain classes where students are using ambiguous names (e.g., “shopping cart,” “shopping basket,” or “shopping trolley”).
Использование предметной области позволяет бороться с двусмысленностью требований.
Частое использование синонимов одних и тех же сущностей экспертами предметной области приводит к двусмысленности. Команда разработки и заказчик могут по разному истолковывать произвольные синонимы, не имеющие определений.
With an initial domain model in place, it’s time to begin writing use cases. Use cases give you a structured way of capturing the behavioral requirements of a system, so that you can reasonably create a design from them. They help you to answer some fundamental questions: What are the users of the system trying to do? What’s the user experience? A surprising amount of what your software does is dictated by the way in which users must interact with it.
Сформулировав предварительную модель модель предметной области, мы переходим к моделированию прецедентов. Моделируя прецеденты мы должны ответить на вопрос — что пользователь будет делать с системой? (Пользователем системы не обязательно является человек. Пользователем системы может выступать другая система)
designing, coding, or estimating directly from a functional spec is like playing an enthralling game of “pick a random number.”
Исходя только из функциональных требования нельзя спроектировать, закодировать или оценить стоимость системы, поэтому нам требуется формализованное описание прецедентов.
Прецеденты должны оперировать терминами предметной области. В ходе моделирования прецедентов уточняются термины предметной области и наоборот.