4. ДЮДЮКИ:
Самая известная
TDD
Test-Driven Development
практика
Нынче очень модное
направление проектирования
DDD Сменщик
Domain-Driven Design BDD TDD
Behaviour-Driven Development
Одна из самых
навороченных
FDD Agile-методологий
VDD
Как затуманить
заказчику мозги
Feature-Driven Development
Value-Driven Development
9. Domain (словарь)
• наследственная собственность; имение,
поместье; земли; владение e.g. DNS
• территория, зона, область, район
(отмеченные некоторыми физическими
особенностями)
• сфера (интересов), поле (деятельности),
область (знаний) В данном случае
этот смысл
• область определения (мат.)
Домен поля
таблицы в БД
10. Т.е. это о
Business Domain
Предметной области
и
Business Logic
Бизнес-логики
11. «Attention was diverted away
from rich logic and deep solutions,
because there was so much value
in just getting data onto the web,
along with very simple behavior.
But now that basic level of web
usage has largely been
assimilated, and projects are
starting to get more ambitious
again about business logic.»
23. Модель –
это упрощенное
Простота != Примитивность
приближение реальности.
Максимально простое,
при условии достаточной
близости к действительности.
35. Модель предметной области; Модель программы;
Словарь терминов Понимание чужого кода
Системная
Бизнес-анализ архитектура
(анализ требований) (проектирование)
Документирование
Понятия из Представление конструкций языка.
предметной области Ограничения по приемам проектирования
Движение слева направо по мере уточнения, детализации и реализации
36. Нюансы терминологии:
Класс Сущность
(class) (entity)
Наследование Обобщение
(inheritance) (generalization)
Функциональность
Свойство Атрибут
(feature)
(property) (attribute)
Метод Операция
(method) (operation)
Ссылка, связь Ассоциация
(reference, link) (association)
ПО Предметная
область
39. • Эксперт: Есть аэропорты. Для каждого известны:
название на местом языке,
уникальный латинский код
и GPS-координаты.
• Мы:
40. • Эксперт: Аэропорты расположены в городах.
Для каждого города известно его
название (на местном и англ. языках).
Причем известно расстояние от аэропорта
до центра города, к которому он «приписан».
• Мы:
41. • Эксперт: Для каждого города есть информация
о стране, в которой он находится.
• Мы:
42. Шаг 4
• Есть информация по рейсам самолетов:
номер рейса (уникален), аэропорты вылета
и прилета
• Время вылета по местному времени
города, из которого производится вылет
• Время прилета по местному времени
города, из которого производится вылет
43.
44. Шаг 5
• Можно ли реализовать вычислимые
атрибуты:
– Время вылета по гринвичу
– Время прилета по гринвичу
– Время в пути
• Если нет, то чего для этого не хватает
(добавьте это на диаграмму вместе с
вычислимыми атрибутами)
45.
46. Шаг 6
• Рейсы делятся на регулярные и чартерные
• Для регулярных рейсов известно
расписание их полетов в днях недели (по
каким дням недели осуществляется рейс)
• Для чартерных рейсов расписание задается
как просто конкретные даты, по которым
выполняется рейс
47.
48. Шаг 7
• Для всех рейсов есть информация по
модели самолета, на которой
осуществляется перелет, со следующими
характеристиками:
– Название модели
– Количество мест эконом-класса
– Количество мест бизнес-класса
– Наличие курящего салона и количество мест в
нём
49. Шаг 8
• Кроме того, для всех рейсов известна компания-
перевозчик
• А у каждого перевозчика есть свой набор тарифов,
каждый из которых определяет:
– Цену билета на соответствующий вид места (бизнес-
класс, эконом-класс, курящий салон)
– Причем цена зависит от степени наполнения самолета
(в каком диапазоне лежит количество проданных
билетов на данный вид мест)
• Тарифы действуют определенный промежуток
времени
• Для рейса известен тариф, по которому продаются
билеты в настоящее время
50. Шаг 9
• В системе есть информация по наличию
свободных мест (для каждого класса) с
учетом возможной брони
• Причем необходимо показывать текущую
цену, по которой в данный момент
продаются билеты заданного класса на
данный рейс (на дату)
51. Шаг 10
• Дальше можно вспомнить что еще бывают
всякие скидки, детские билеты, перенос
рейсов, отмена и т.д.
• НО МЫ ЭТОГО ДЕЛАТЬ НЕ БУДЕМ
58. Feature-Driven Development (FDD):
Разработка Составление Планирование
общей модели списка функций
Список функций План разработки
(Feature list) (A development plan)
1 – 3 недели
Design by Build by feature
Диаграмма классов feature
предметной области
Отгрузка!
60. III. Реализация в коде
Шаблоны / Варианты архитектур /
Распределенные дилеммы
61. СУБД Модель ОО-язык
таблица сущность класс
поле атрибут свойство
FK cвязь ссылка
хранимая
действие метод
процедура
62.
63.
64.
65. Идентификация:
- два объекта, один и тот же аэропорт
Жизненный цикл объекта:
- создание /модификация / удаление
Создание
Отражение в
Чтение из хранилище
Модификация
хранилища
Удаление из
хранилища
79. Value object
• Неизменность объекта (Immutable)
– можно безопасно передавать
• Сравнение объектов = сравнение данных
– позволяет распознавать одинаковые значения,
представленные в виде разных объектов
• Инкапсулирует проверку корректности значения
– «Build-in anticorruption layer»
• Обеспечивает строгую типизацию
– случайно не передашь Code вместо Name и наоборот
80.
81.
82.
83.
84.
85.
86.
87. Mapping этого хозяйства на БД
AIRPORTS
CODE (PK) NAME LATITUDE LONGITUDE
DME Домодедово 12345 67890
92. Задача
Во многих местах логики и тестов
создавать рейс по:
• Код аэропорта Откуда
• Код аэропорта Куда
• UN модели самолета
• ИНН компании перевозчика
95. Сервисы
• Уровня доменной модели (Domain Servicies)
– Инфраструктурные (API к системе сообщений, API
для интеграции с внешними системами, …)
– Согласованная работа с несколькими объектами
(«уволить всех сотрудников на заданную букву», …)
– Комбинированная алгоритмика (прокладка
маршрутов, подбор оптимальных вариантов, …)
• Уровня приложения (Application Servicies)
– чуть позже
102. UI (User Interface):
the easiest to understand, this layer is the
responsible of displaying information to the user,
and accept new data. It could be implemented for
web, desktop, or any presentation technology,
present or future. For example, it could be a voice
application, that interacts with the user via a phone.
The acid test for our design is that a radical change
in user interface should have minimal (or controlled,
at least) impact in the rest of the system.
103. Application Layer:
it’s in charge of coordinating the actions to be
performed on the domain. There are no business
rules or domain knowledge here. No business state
resides in this layer. It delegates all domain actions
to the domain. It could coordinate many actions
(possibly in many domains). It could prepare the
infrastructure to be ready to work with the domain
for an specific action (for example, preparing
transaction scopes).
104. Domain Layer:
In this layer resides the heart of software, according
to Evans. Business rules and logic lives inside this
layer. Business entity state and behavior is defined
and used here. Communication with other systems,
persistence details, are forwarded to the
infrastruсture layer. Patterns: Entities, Value Objects,
Services, Repositories and Factories.
105. Infrastructure Layer:
God and devil are in the details, and in the
infrastructure layer. Its main responsability is the
persistence of the business state, most frequently,
using a relational database.
The infrastructure consists of everything that exists
independently of our application: external libraries,
database engine, application server, messaging
backend and so on.
108. Interface:
This layer holds everything that interacts with other
systems, such as web services, RMI interfaces or
web applications, and batch processing frontends. It
handles interpretation, validation and translation of
incoming data. It also handles serialization of
outgoing data, such as HTML or XML across HTTP to
web browsers or web service clients, or DTO classes
and distributed facade interfaces for remote Java
clients.
109. Infrastructure:
Infrastructure consists of everything that exists
independently of our application: external libraries,
database engine, application server, messaging
backend and so on.
Also, we consider code and configuration files that
glues the other layers to the infrastructure as part of
the infrastructure layer. Looking for example at the
persistence aspect, the database schema definition,
Hibernate configuration and mapping files and
implementations of the repository interfaces are
part of the infrastructure layer.
110. Infrastructure
Application
Framework Model
?
Domain
Persistance
111. Rich Pure
Domain Model Domain Model
Model Model
IoC
Persistance Persistance
112. Model
Domain Model
Airport AirportRepository Mapping
Metadata
Rich
Persistance
EnityBase RepositoryBase Utils
113. Model
Airport AirportRepository
Domain Model
Pure
«depends»
«implement»
Persistance
Mapping AirportRepository
Utils
Metadata Impl
114. A Pure Object-oriented Domain Model
by a DB Guy
http://www.devx.com/vb2themax/Article/19892/0/page/1
http://www.devx.com/vb2themax/Article/19892/0/page/2
http://www.devx.com/vb2themax/Article/19892/0/page/3
http://www.devx.com/vb2themax/Article/19892/0/page/4
115. А еще есть
(анти?)паттерн
Anemic Domain Model
http://www.martinfowler.com/bliki/AnemicDomainModel.html
• Набор getter-ов и setter-ов == Typed Record
• Вся логика в сервисах в процедурном стиле