Здравствуйте, perekrestov, Вы писали:

P>>>А это не приводит к анемичной модели со всеми вытикающими последствиями?
S>>Озвучите последствия — озвучу как мы с ними боремся (или не боремся)
P>Ну, о приимуществах/недостатках повторяться не хочется. Тут

Автор: GlebZ
Дата: 27.05.09

все хорошо обсудили
P>Могу, конечно, скопипастить с wiki
А, абстрактные страшилки Не, с ними не боремся Большинство аргументов в списке из разряда "Дайте игрушку индусокодеру и он её сломает. Чугуний надёжней."

Ну как, скажите мне, разделение кода по слоям может привести к "Facilitates code duplication among transactional scripts"? Рефакторинг не нужен(с)? Остальной бред комментировать не хоцца.


P>Меня интересует реализация. Как реализовать/спроектировать упомянутую мною проблему следуя DDD.
Так вы определитесь, какой DDD вам нужен Я про один DDD, Ziaw — про другой, он предлагает смешивать в модели и предметную область, и бизнес-логику. У всех личные тараканы в голове, у каждого приёма — тыщща толкователей.

А на практике никто не оглядывается на паттерны, и делает так, как правильно/принято/удобно в текущих условиях, с существующей системой и с используемыми технологиями.

P>Основная цель, которую я перед собой поставил — определить возможность хранения БЛ совместно с сущностями
Зря. Цикл жизни данных на порядки больше, чем БЛ и для заказчика они куда важнее самой бесценной системы.

Здравствуйте, perekrestov, Вы писали:

P>Здравствуйте, gandjustas, Вы писали:



G>>Во расскажи для начала какие задачи решают твои entity и репозитарии?

P>Основная цель, которую я перед собой поставил — определить возможность хранения БЛ совместно с сущностями, за что и агитирует Эванс.
Так не стоит делать. Эванс мягко говоря обманывает. Если посмотреть примеры приложений в стиле DDD, то там всегда существует некоторый слой, где данные отделены от методов.

P>Проблема в том, что эта логика может требовать некоторой обработки данных, которые не всегда можно получить тривиальным способом.
P>Например, есть сущность Customer

P>Нам нужно определить является ли этот кастомер GoldCustomer.

P>(Опустим Specification Pattern, т.к. он проблемы в описываемом случае не решает.)

P>class Customer
P>{
P> public bool IsGoldCustomer(){
P> // Вот тут нам понадобятся данные за какаой-то период времени или что=-т подобное
P> // И очень вероятно, нам нужно будет обратиться в базу со сложным запросом
P> }
P>}

А почему не

public bool IsGoldCustomer(int customerId)

?

иди даже получать статус кастомера при запросе его из базы.

P>+ еще хочется реализовать это так, чтобы эту логику можно было тестировать. Другими словами, я хотелбы мочить (от слова mock) репозитории.
Если у тебя репозиторий отдает IQueryable<T>, то тестируется он отлично.


P>Вопрос состоит в том, насколько "красивым"/"правилиным" является такое решение. У меня нет опыта написания приложений с использованием DDD, вот меня и интересует, как поступают коллеги при решении описанной проблемы.

"Красивость" и "правильность" это не те критерии, которыми стоит руководствоваться.

Здравствуйте, Sinix, Вы писали:

P>>Иногда, сложная бизнес логика требует взаимодействия с БД и "хитрой" выборкой данных.
P>>Например, в конкретной сущности у меня есть метод DoSomethingComplex()

S>Я предпочитаю отделять мухи от котлет: модель данных — отдельно, поведение приложения — отдельно (в контроллерах). Соответственно, DoSomethingComplex() у меня жило бы в каком-нить ComplexController, который сам бы разруливал работу с данными в зависимости от бизнес-логики. Бонус — при изменении логики модель данных портить не надо

А это не приводит к анемичной модели со всеми вытикающими последствиями?


S>Да, в результате репозитария как такового нет

Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, perekrestov, Вы писали:

P>>А это не приводит к анемичной модели со всеми вытикающими последствиями?
S>Озвучите последствия — озвучу как мы с ними боремся (или не боремся)


Ну, о приимуществах/недостатках повторяться не хочется. Тут

Автор: GlebZ
Дата: 27.05.09

все хорошо обсудили

Могу, конечно, скопипастить с wiki

Logic cannot be implemented in a truly object-oriented way unless wrappers are used, which hide the anemic data structure.

Violation of the encapsulation and information hiding principles.

Necessitates a separate business layer to contain the logic otherwise located in a domain model. It also means that domain model's objects cannot guarantee their correctness at any moment, because

their validation and mutation logic is placed somewhere outside (most likely in multiple places).

Necessitates a global access to internals of shared business entities increasing coupling and fragility.

Facilitates code duplication among transactional scripts and similar use cases, reduces code reuse.

Necessitates a service layer when sharing domain logic across differing consumers of an object model.

Makes a model less expressive and harder to understand.

Но, меня не сильно интересует вопрос Anemic vs Rich domain model.

Меня интересует реализация. Как реализовать/спроектировать упомянутую мною проблему следуя DDD.

S>У нас модель данных отвечает за структуру и инварианты предметной области (разумеется речь не о всей модели, а об её представлении для конкретного клиента), контроллеры — за поведение приложения в соответствии с БЛ заказчика. Каждая часть решает свою задачу, смешивать их не хотим.

Здравствуйте, perekrestov, Вы писали:

P>А это не приводит к анемичной модели со всеми вытикающими последствиями?
Озвучите последствия — озвучу как мы с ними боремся (или не боремся)

У нас модель данных отвечает за структуру и инварианты предметной области (разумеется речь не о всей модели, а об её представлении для конкретного клиента), контроллеры — за поведение приложения в соответствии с БЛ заказчика. Каждая часть решает свою задачу, смешивать их не хотим.

Здравствуйте, Sinix, Вы писали:

S>Так вы определитесь, какой DDD вам нужен Я про один DDD, Ziaw — про другой, он предлагает смешивать в модели и предметную область, и бизнес-логику. У всех личные тараканы в голове, у каждого приёма — тыщща толкователей.

Не затруднит ли уважаемого дона привести примеры моих высказываний где я предлагаю смешивать все в модели?

Здравствуйте, perekrestov, Вы писали:

P>Здравствуйте, Aviator, Вы писали:


P>>>Я понимаю, что это решается через DI. И, например, если я использую NHibernate я могу инъектить зависомости во время дегидрации используя интерсепторы.
A>>Сурово
P>Вроде как нормально
Что нормального?

P>Domain Driven Design and Development In Practice

P>

P>Dependency Injection

P>DI is a great way to move the configuration and dependency code out of the domain objects. Also, the design dependency of domain classes on Data Access Object (DAO) classes and service classes on domain classes makes DI a "must have" in DDD implementation. DI facilitates a cleaner and loosely coupled design by injecting the other objects such as Repositories and Services into Domain Objects.

P>In the sample application, the service object (FundingServiceImpl) uses DI to inject the Entity objects (Loan, Borrower and FundingRequest). Also, Entities reference Repositories via DI. Similarly, other Java EE resources like DataSource, Hibernate Session Factory and Transaction Manager are injected into Service and Repository objects.

Помещать доступ к данным, даже через интерфейс в доменный объект ... В итоге получаем огромные сущности с набором данных и кучей логики внутри. Не забываем кстати, что логика меняется чаще данных. И вообще, если очень хочется, что бы триггером начала обработки был вызов метода доменного объекта, то тогда уж domain events. А если по простому, то сложные действия лучше делать через набор служб, которые переколбасят доменные объекты как нужно.

Добрый день,

Возник вопрос о том, как Entity взаимодействуют с репозиториями.

Иногда, сложная бизнес логика требует взаимодействия с БД и "хитрой" выборкой данных.

Например, в конкретной сущности у меня есть метод DoSomethingComplex()

И в этом методе мне требуются дополнительные данные, которые не принадлежат текущей сущности.

Как организовать обращение Entity к репозиториям?

Стоит ли инжектить необходимые репозитории в Entity?

И стоит ли использовать, вообще, IoC относительно Entity?

Спасибо.

Здравствуйте, perekrestov, Вы писали:

P>Добрый день,

P>Возник вопрос о том, как Entity взаимодействуют с репозиториями.
Как вам нравится На практике всё оперделяется задачей/типом приложения/используемыми средствами/религиозными предпочтениями разработчика. Например Эванс (при всём уважении к нему как к популяризатору DDD) — последовательно примазывался к яваистам, затем раскланивался с agile до такой степени, что окончательно опошлил светлые идеалы DDD, а щас агитирует за NoSQL. Евангелист, работа такая. Поэтому все заветы гурей(ов?) неплохо бы делить на 256.

И под репозитарими, и под сущностями каждый понимает свои собственные домыслы (и готов их отстаивать вплоть до почётного банного веника), так что всё, о чём вам тут могут рассказать — это "как делаем мы".

Например, я очень люблю data-driven подход (хоть и несколько вынужденно: когда основная фича системы — согласованная работа с данными в весьма разных клиентах, по-другому не попляшешь) и проектирование от модели предметной области заказчика. Если щас появится ув gandjustas — он будет агитировать за более практично-приземлённый подход "делать щас что надо а там разберёмся" (я передёргиваю и вообще заведомо неправ ). Что нравится вам — то и выбирайте.

Как делаем мы — писал тут

Автор: Sinix
Дата: 10.02.09

(только этот конкретный пост, последующая простыня унылого флейма ничего ценного в себе не несёт).

P>Иногда, сложная бизнес логика требует взаимодействия с БД и "хитрой" выборкой данных.
P>Например, в конкретной сущности у меня есть метод DoSomethingComplex()

Я предпочитаю отделять мухи от котлет: модель данных — отдельно, поведение приложения — отдельно (в контроллерах). Соответственно, DoSomethingComplex() у меня жило бы в каком-нить ComplexController, который сам бы разруливал работу с данными в зависимости от бизнес-логики. Бонус — при изменении логики модель данных портить не надо

Да, в результате репозитария как такового нет

Здравствуйте, perekrestov, Вы писали:

P>Добрый день,

P>Возник вопрос о том, как Entity взаимодействуют с репозиториями.

P>Иногда, сложная бизнес логика требует взаимодействия с БД и "хитрой" выборкой данных.

P>Например, в конкретной сущности у меня есть метод DoSomethingComplex()

P>И в этом методе мне требуются дополнительные данные, которые не принадлежат текущей сущности.

P>Как организовать обращение Entity к репозиториям?

P>Стоит ли инжектить необходимые репозитории в Entity?

P>И стоит ли использовать, вообще, IoC относительно Entity?



Во расскажи для начала какие задачи решают твои entity и репозитарии?

По мне так вообще entity не нужны. В крайнем случае dto-подобные классы для переноса данных, остальное можно ридерами.
При наличии Linq, все еще проще: типизированныая модель данных создается автоматом, типизрованные проекции тоже есть.

Методы БЛ получают на вход ровно тот набор данных, который необходим. Репозитарии отдают данные из базы в ответ на некоторый query object.

Здравствуйте, gandjustas, Вы писали:



G>Во расскажи для начала какие задачи решают твои entity и репозитарии?

Основная цель, которую я перед собой поставил — определить возможность хранения БЛ совместно с сущностями, за что и агитирует Эванс.
Проблема в том, что эта логика может требовать некоторой обработки данных, которые не всегда можно получить тривиальным способом.
Например, есть сущность Customer

Нам нужно определить является ли этот кастомер GoldCustomer.

(Опустим Specification Pattern, т.к. он проблемы в описываемом случае не решает.)

class Customer
{
public bool IsGoldCustomer(){
// Вот тут нам понадобятся данные за какаой-то период времени или что=-т подобное
// И очень вероятно, нам нужно будет обратиться в базу со сложным запросом
}
}


+ еще хочется реализовать это так, чтобы эту логику можно было тестировать. Другими словами, я хотелбы мочить (от слова mock) репозитории.

Я понимаю, что это решается через DI. И, например, если я использую NHibernate я могу инъектить зависомости во время дегидрации используя интерсепторы.

Вопрос состоит в том, насколько "красивым"/"правилиным" является такое решение. У меня нет опыта написания приложений с использованием DDD, вот меня и интересует,

как поступают коллеги при решении описанной проблемы.

Здравствуйте, perekrestov, Вы писали:

P>Меня интересует реализация. Как реализовать/спроектировать упомянутую мною проблему следуя DDD.

Следуя DDD ваша сущность должна включать в себя или иметь путь ко всем нужным для логики данным.

Т.е. ей надо замапить ленивую коллекцию строк хитрой выборки.

Впрочем это тоже не серебряная пуля, с таким подходом все равно рано или поздно понадобится прямой
доступ к ORM из модели. Как вариант запоминать точку доступа в thread local контексте.

Здравствуйте, perekrestov, Вы писали:

P>Я понимаю, что это решается через DI. И, например, если я использую NHibernate я могу инъектить зависомости во время дегидрации используя интерсепторы.
По-простому конкретно в NHibernate вы можете пойти по относительно кривому пути rich model, то есть IsGoldCustomer сделать readonly-свойством и атрибутами попросить NHibernate заполнять его значение результатом соответствующего SQL-запроса (не HQL); разумеется, лениво. Но это не хорошо, так как если заказчик сам по себе не владеет информацией о том, золотой он или нет (на уровне определенных domain model, это не про жизнь, конечно), то этот метод не является областью его ответственности, соответственно, должно быть вне его.

Инача, можно определять DAO-объекты в виде наследников общего интерфейса IDAO<T> (это вам поможет и с mock-ами, и с DI), содержащие кроме CRUID-операцией (обычно легко вынести в базовую типизированную реализацию DAO<T>: IDAO<T>). В конструктор соответствующего DAO-объекта передавать интерфейсным контрактом зависимые IDAO<T> (constructor injection, потом можно собирать IoC-контейнером), которые он будет использовать для выполнения комплексных запросов к хранилищу (кроме графа связанных объектов предметной области получится также граф связанных DAO-объектов). К примеру, CustomerDAO: IDAO<Customer> принимает в конструктор IDAO<CustomerHistoryDAO> и предоставляет методы вроде GetAllGoldCustomers() и IsGoldCutomer(Customer obj).

Здравствуйте, perekrestov, Вы писали:

P>class Customer
P>{
P> public bool IsGoldCustomer(){
P> // Вот тут нам понадобятся данные за какаой-то период времени или что=-т подобное
P> // И очень вероятно, нам нужно будет обратиться в базу со сложным запросом
P> }
P>}

Я понимаю что это не общее, а частное решении для проблемы (а может и не решение вовсе).
Что если сделать такой атрибут в бд (isGoldCustomer) и сделать шедулер который обновляет этот атрибут с заданной периодичностью.

Выигрыш в производительности как бонус (допускаю что не очень ощутимый).

Здравствуйте, Ziaw, Вы писали:


S>>Так вы определитесь, какой DDD вам нужен Я про один DDD, Ziaw — про другой, он предлагает смешивать в модели и предметную область, и бизнес-логику. У всех личные тараканы в голове, у каждого приёма — тыщща толкователей.

Z> Не затруднит ли уважаемого дона привести примеры моих высказываний где я предлагаю смешивать все в модели?
Затруднит С некоторой натяжкой вот это

Следуя DDD ваша сущность должна включать в себя или иметь путь ко всем нужным для логики данным.

можно трактовать как "структура модели данных должна определяться бизнес-логикой", но вы ведь не совсем это имели в виду.

Здравствуйте, perekrestov, Вы писали:

P>Здравствуйте, gandjustas, Вы писали:



G>>Во расскажи для начала какие задачи решают твои entity и репозитарии?

P>Основная цель, которую я перед собой поставил — определить возможность хранения БЛ совместно с сущностями, за что и агитирует Эванс.
P>Проблема в том, что эта логика может требовать некоторой обработки данных, которые не всегда можно получить тривиальным способом.
P>Например, есть сущность Customer

P>Нам нужно определить является ли этот кастомер GoldCustomer.

P>(Опустим Specification Pattern, т.к. он проблемы в описываемом случае не решает.)

P>class Customer
P>{
P> public bool IsGoldCustomer(){
P> // Вот тут нам понадобятся данные за какаой-то период времени или что=-т подобное
P> // И очень вероятно, нам нужно будет обратиться в базу со сложным запросом
P> }
P>}

P>+ еще хочется реализовать это так, чтобы эту логику можно было тестировать. Другими словами, я хотелбы мочить (от слова mock) репозитории.

Я бы сделал отдельную службу с методом IsGold(Customer customer). В доменные объекты помещаю только сравнительно простую логику, не требующую взаимодействия с внешним миром (БД, внешние службы...). Хотя в данной конкретной ситуации, почему бы не сделать такое поле в классе Customer (= таблице) и не обновлять при определённых условиях?

P>Я понимаю, что это решается через DI. И, например, если я использую NHibernate я могу инъектить зависомости во время дегидрации используя интерсепторы.
Сурово

P>Вопрос состоит в том, насколько "красивым"/"правилиным" является такое решение. У меня нет опыта написания приложений с использованием DDD, вот меня и интересует,
Правильно то, что работает и потребляет допустимое условиями задачи количество ресурсов и время. Ну и поддержка не требует наличия группы из гуру программирования.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, perekrestov, Вы писали:

P>>class Customer
P>>{
P>> public bool IsGoldCustomer(){
P>> // Вот тут нам понадобятся данные за какаой-то период времени или что=-т подобное
P>> // И очень вероятно, нам нужно будет обратиться в базу со сложным запросом
P>> }
P>>}

А>Я понимаю что это не общее, а частное решении для проблемы (а может и не решение вовсе).
А>Что если сделать такой атрибут в бд (isGoldCustomer) и сделать шедулер который обновляет этот атрибут с заданной периодичностью.

А>Выигрыш в производительности как бонус (допускаю что не очень ощутимый).

Обычно статус учитывается в момент покупки. Вот и делай обновление чтобы в момент покупки статус был актуален

Здравствуйте, Aviator, Вы писали:


A>Я бы сделал отдельную службу с методом IsGold(Customer customer). В доменные объекты помещаю только сравнительно простую логику, не требующую взаимодействия с внешним миром (БД, внешние службы...). Хотя в данной конкретной ситуации, почему бы не сделать такое поле в классе Customer (= таблице) и не обновлять при определённых условиях?

P>>Я понимаю, что это решается через DI. И, например, если я использую NHibernate я могу инъектить зависомости во время дегидрации используя интерсепторы.
A>Сурово
Тут проблема не в самом методе. Если я не ошибаюсь, для таких вещей Эванс рекомендует использовать Specification pattern

Я хотел показать следущее. Вот если Entity понадобится взаимодействовать с упомянутым вами сервисом.

Тогда как эта сущность должна получать на него ссылку?

Например, при покупке товара ГолдКастомером ему начисляется скидка, бонусы или что-то в этом роде.

Customer customer;
// тут получили ссылку на него каким-то образом.

Product p;
// получили ссылку на товар

customer.Buy(p);

(пример с покупкой я вытянул с головы).

У меня сложилось такое ощущение, что многие пытаются выносить более-мение сложную логику в бизнес сервисы из сущностей, т.к.
Но ведь это приводит к анимичной модели... А хочется все-таки понять как добиться на практике того, о чем говорит Эванс.

Customer customer;
// тут получили ссылку на него каким-то образом.

Product p;
// получили ссылку на товар

PaymentService ps = serviceLocator.Resolve<IPaymentService>();

ps.BuyProduct(customer, p);

P>>Вопрос состоит в том, насколько "красивым"/"правилиным" является такое решение. У меня нет опыта написания приложений с использованием DDD, вот меня и интересует,
A>Правильно то, что работает и потребляет допустимое условиями задачи количество ресурсов и время. Ну и поддержка не требует наличия группы из гуру программирования.

Здравствуйте, Aviator, Вы писали:


P>>Я понимаю, что это решается через DI. И, например, если я использую NHibernate я могу инъектить зависомости во время дегидрации используя интерсепторы.
A>Сурово
Вроде как нормально

Domain Driven Design and Development In Practice

Dependency Injection

DI is a great way to move the configuration and dependency code out of the domain objects. Also, the design dependency of domain classes on Data Access Object (DAO) classes and service classes on domain classes makes DI a "must have" in DDD implementation. DI facilitates a cleaner and loosely coupled design by injecting the other objects such as Repositories and Services into Domain Objects.

In the sample application, the service object (FundingServiceImpl) uses DI to inject the Entity objects (Loan, Borrower and FundingRequest). Also, Entities reference Repositories via DI. Similarly, other Java EE resources like DataSource, Hibernate Session Factory and Transaction Manager are injected into Service and Repository objects.

Здравствуйте, perekrestov, Вы писали:

P>>>Я понимаю, что это решается через DI. И, например, если я использую NHibernate я могу инъектить зависомости во время дегидрации используя интерсепторы.
A>>Сурово
P>Тут проблема не в самом методе. Если я не ошибаюсь, для таких вещей Эванс рекомендует использовать Specification pattern

Интереснее всего читать самое начало эванса http://domaindrivendesign.org/sites/default/files/books/chapter01.pdf

1)Не указаны задачи, решаемые создаваемой программой
2)Не указано почему сначала создавалась именно структура, а потом функции
3)Не понятно почему модель предметной области 1-в-1 была отображена на классы с "поведением"

Все эти фундаментальные для программы решения никак не обоснованы эвансом.

Здравствуйте, gandjustas, Вы писали:

G>1)Не указаны задачи, решаемые создаваемой программой

Вообще то ответ на это есть в книге в той самой первой главе.

G>2)Не указано почему сначала создавалась именно структура, а потом функции

И структура и функции. Структура важнее, потому что для описания функции нужны уже конкретные термины.

Функционалисты постоянно про это забывают. Для общеупотребительных случаев функциональный дизайн делается легко и просто. А вот когда область нужно раскапывать, то до функций еще дойти надо.

G>3)Не понятно почему модель предметной области 1-в-1 была отображена на классы с "поведением"

Не ясно, что ты имел ввиду.

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, gandjustas, Вы писали:

G>>1)Не указаны задачи, решаемые создаваемой программой
I>Вообще то ответ на это есть в книге в той самой первой главе.
Я не нашел, приведешь цитату?

G>>2)Не указано почему сначала создавалась именно структура, а потом функции
I>И структура и функции. Структура важнее, потому что для описания функции нужны уже конкретные термины.
Нет, именно сначала структура, а потом функции. Причем самое интересное что очень много времени отведено именно поиску подходящих названий, а про группировку функций не сказано ничего, кроме "brainstorming". Хотя правильное разделение обязанностей (функций) — один из основных вопросов архитектуры.

I>Функционалисты постоянно про это забывают. Для общеупотребительных случаев функциональный дизайн делается легко и просто. А вот когда область нужно раскапывать, то до функций еще дойти надо.
Это кто тебе такую глупость сказал? Как раз функции найти легко, они непосредственно выводятся из пожеланий (требований) пользователей. А вот структура предметной области как раз подлежит "раскапыванию", именно об этом и вся первая глава книги эванса. Вот только никто не гарантирует что раскопанная структура будет адекватна для решаемых задач.


G>>3)Не понятно почему модель предметной области 1-в-1 была отображена на классы с "поведением"
I>Не ясно, что ты имел ввиду.
Ну например имея нарисованную ER диаграмму предметной области не обязательно её 1-в-1 переводить в классы. Зачастую это излишне.

Здравствуйте, gandjustas, Вы писали:

G>>>1)Не указаны задачи, решаемые создаваемой программой
I>>Вообще то ответ на это есть в книге в той самой первой главе.
G>Я не нашел, приведешь цитату?

Он говорит про программу проектирования печатных плат. Это означает набор определенных задач.

Далее он рассказывает про стуктуру модели на примере функции "прозванивание".

Диалог внимательно прочти "мы ищем долгие задержки сигнала...если путь прохождения сигнала слишком длинный...вычислить длину пути...переприем...прозванивание топологии..."

I>>И структура и функции. Структура важнее, потому что для описания функции нужны уже конкретные термины.
G>Нет, именно сначала структура, а потом функции.

Конечно. Сначала структура, потому что она важнее, а потом — функции, потому что для них нужны уже конкретные термины.

>Причем самое интересное что очень много времени отведено именно поиску подходящих названий,

Да, он и пишет — "ввели в обиход язык основаный на модели"

>а про группировку функций не сказано ничего, кроме "brainstorming". Хотя правильное разделение обязанностей (функций) — один из основных вопросов архитектуры.

Функции надо вычислить. Сначала челы выяснили, в чем заключается прозванивание цепи. Потом адаптировали под это дело модель

Эванс вообще все делает через рефакторинг и тестирование, то есть он не рожает готовые решения

I>>Функционалисты постоянно про это забывают. Для общеупотребительных случаев функциональный дизайн делается легко и просто. А вот когда область нужно раскапывать, то до функций еще дойти надо.
G>Это кто тебе такую глупость сказал? Как раз функции найти легко, они непосредственно выводятся из пожеланий (требований) пользователей.

Вот тебе такая функция — проектирование оптических сетей, cost based mesh design скажем для SONET.

Валяй, пиши что ты из этого понял и как это приспособить к дизайну.

>А вот структура предметной области как раз подлежит "раскапыванию", именно об этом и вся первая глава книги эванса. Вот только никто не гарантирует что раскопанная структура будет адекватна для решаемых задач.

Если задачу прозванивания можно решить на предложеной структуре, значит структура подходящая для задачи прозванивания.

G>>>3)Не понятно почему модель предметной области 1-в-1 была отображена на классы с "поведением"
I>>Не ясно, что ты имел ввиду.
G>Ну например имея нарисованную ER диаграмму предметной области не обязательно её 1-в-1 переводить в классы. Зачастую это излишне.

Необязательно, да. А иногда только так и можно. Он не пояснил свой выбор. Я правда, дальше первой главы не прочел, может дальше что будет, только на этой недели книга пришла.

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, gandjustas, Вы писали:

G>>>>1)Не указаны задачи, решаемые создаваемой программой
I>>>Вообще то ответ на это есть в книге в той самой первой главе.
G>>Я не нашел, приведешь цитату?

I>Он говорит про программу проектирования печатных плат. Это означает набор определенных задач.
Ага, только потом он сам признается что не понимает что есть "проектирование печатных плат" и дальше про задачи, решаемые программой, не заикается.
Уж очень профессиональный подход...

I>Далее он рассказывает про стуктуру модели на примере функции "прозванивание".
Это он описывает модель, а не функцию системы. Как это ложится на функцию системы — непонятно.

I>Диалог внимательно прочти "мы ищем долгие задержки сигнала...если путь прохождения сигнала слишком длинный...вычислить длину пути...переприем...прозванивание топологии..."
Непонятно зачем это.

I>>>И структура и функции. Структура важнее, потому что для описания функции нужны уже конкретные термины.
G>>Нет, именно сначала структура, а потом функции.
I>Конечно. Сначала структура, потому что она важнее, а потом — функции, потому что для них нужны уже конкретные термины.
Структура без функций никому не нужна. Структура является средством реализации функций.
А тут получается что эванс рисует структуру, даже без намека на функции. А потом из воздуха берет функции и они по счастливому стечению обстоятельств хорошо ложатся на функции.

>>Причем самое интересное что очень много времени отведено именно поиску подходящих названий,
I>Да, он и пишет — "ввели в обиход язык основаный на модели"
Это далеко не самое главное.

>>а про группировку функций не сказано ничего, кроме "brainstorming". Хотя правильное разделение обязанностей (функций) — один из основных вопросов архитектуры.
I>Функции надо вычислить. Сначала челы выяснили, в чем заключается прозванивание цепи.
А я так и не понял в чем оно заключается. Вот есть программа, которая делает "прозваниевание цепи". Как ей пользоваться? Что она вообще делает? Ты сможешь это объяснить по описанию эванса?

I>Потом адаптировали под это дело модель
То есть структура (модель) меняется в зависимости от функций? Тогда зачем столько усилий по созданию сначала структуры?

I>Эванс вообще все делает через рефакторинг и тестирование, то есть он не рожает готовые решения
И что? То что он делает через тестирование делает его решение однозначно правильным? Как вообще понять что он делает то что нужно (то что приближает его к решению проблем\задач пользователей)?

I>>>Функционалисты постоянно про это забывают. Для общеупотребительных случаев функциональный дизайн делается легко и просто. А вот когда область нужно раскапывать, то до функций еще дойти надо.
G>>Это кто тебе такую глупость сказал? Как раз функции найти легко, они непосредственно выводятся из пожеланий (требований) пользователей.

I>Вот тебе такая функция — проектирование оптических сетей, cost based mesh design скажем для SONET.
И?

I>Валяй, пиши что ты из этого понял и как это приспособить к дизайну.
Где требования\пожелания пользователей?

Это ты написал примерно как "создать графический редактор"... Вроде даже все знают что такое графический редактор, но такой постановки в принципе недостаточно чтобы даже начинать что-то делать.

>>А вот структура предметной области как раз подлежит "раскапыванию", именно об этом и вся первая глава книги эванса. Вот только никто не гарантирует что раскопанная структура будет адекватна для решаемых задач.

I>Если задачу прозванивания можно решить на предложеной структуре, значит структура подходящая для задачи прозванивания.
То есть сначала таки надо получить набор задач, чтобы понять что конкретная структура подходит?
А если вдруг не подходит, то переделывать структуру?

Отличная статья на эту тему из соседнего вопроса.

ЗЫ. Кстати эванс описывает в книге задачe моделирования (ну по крайней мере они свел задачу к моделированию), что хорошо решается средствами ООП. Большинство бизнес-задач не являются задачами моделирования, и предложенным способом решаются плохо. Ту в книге не увидел обоснований что данный способ (DDD) хорошо подходит для других задач.

Здравствуйте, gandjustas, Вы писали:

I>>Он говорит про программу проектирования печатных плат. Это означает набор определенных задач.
G>Ага, только потом он сам признается что не понимает что есть "проектирование печатных плат" и дальше про задачи, решаемые программой, не заикается.
G>Уж очень профессиональный подход...

А где взять программиста, который специалист по проектированию печетных плат ?

I>>Далее он рассказывает про стуктуру модели на примере функции "прозванивание".
G>Это он описывает модель, а не функцию системы. Как это ложится на функцию системы — непонятно.

Именно так — сначала разбирается с тем, что же ему надо делать. В такой области как у него с печатными платами как правило нет людей, которые умеют и программировать и ТЗ написать и задачи решать в терминах предметной области.

I>>Диалог внимательно прочти "мы ищем долгие задержки сигнала...если путь прохождения сигнала слишком длинный...вычислить длину пути...переприем...прозванивание топологии..."
G>Непонятно зачем это.

Это уточняется что же такое прозвон цепи.

I>>Конечно. Сначала структура, потому что она важнее, а потом — функции, потому что для них нужны уже конкретные термины.
G>Структура без функций никому не нужна. Структура является средством реализации функций.

Он от функций никуда не уходит. Диалог про проработку одной функции — прозванивание.

G>А тут получается что эванс рисует структуру, даже без намека на функции. А потом из воздуха берет функции и они по счастливому стечению обстоятельств хорошо ложатся на функции.

Наоборот — ищет структуру для конкретной функции. Потом пишет, что то же самое было проделано под все функции. Читай диалог внимательно.

I>>Да, он и пишет — "ввели в обиход язык основаный на модели"
G>Это далеко не самое главное.

Он с тобой не согласен.

I>>Функции надо вычислить. Сначала челы выяснили, в чем заключается прозванивание цепи.
G>А я так и не понял в чем оно заключается. Вот есть программа, которая делает "прозваниевание цепи". Как ей пользоваться? Что она вообще делает? Ты сможешь это объяснить по описанию эванса?

Программа может быть любая — серверная, десктоп, мобильная, веб-приложение. Что она делает — выполняет рассчеты определенные.

I>>Потом адаптировали под это дело модель
G>То есть структура (модель) меняется в зависимости от функций? Тогда зачем столько усилий по созданию сначала структуры?

Конечно, структура будет меняться. Например был у тебя cost based design а понадобился еще и period based design — это изменение модели. К

I>>Эванс вообще все делает через рефакторинг и тестирование, то есть он не рожает готовые решения
G>И что? То что он делает через тестирование делает его решение однозначно правильным? Как вообще понять что он делает то что нужно (то что приближает его к решению проблем\задач пользователей)?

I>>Вот тебе такая функция — проектирование оптических сетей, cost based mesh design скажем для SONET.
G>И?

Тебе ничего из этого непонятно, правда ?

I>>Валяй, пиши что ты из этого понял и как это приспособить к дизайну.
G>Где требования\пожелания пользователей?

У меня этого почти никогда не было, за 10 лет

G>Это ты написал примерно как "создать графический редактор"... Вроде даже все знают что такое графический редактор, но такой постановки в принципе недостаточно чтобы даже начинать что-то делать.

Конечно. В этом вся фишка, когда нужно лезь куда то, кроме как "заказчик-заказ-позиция" или "фигуры", надо начинать с самых азов, т.е. с базовых понятий. Только потому, что кастомер часто вообще не имеет представления о программировании.

I>>Если задачу прозванивания можно решить на предложеной структуре, значит структура подходящая для задачи прозванивания.
G>То есть сначала таки надо получить набор задач, чтобы понять что конкретная структура подходит?

Конечно, кастомер должен хотя бы высказать, чего же он хочет. Наприер — рассчет прозвона.

G>А если вдруг не подходит, то переделывать структуру?

Более того — переделывать постоянно, в т.ч. под конкретную задачу, как прозвон. Он ведь именно это и демонстрирует. А потом пишет, что все то же было проделано для всех функций.

G>Отличная статья на эту тему из соседнего вопроса.

Это не интересно. Фигуры всякие это для школьников.

G>Большинство бизнес-задач не являются задачами моделирования, и предложенным способом решаются плохо. Ту в книге не увидел обоснований что данный способ (DDD) хорошо подходит для других задач.

А он и не утверждает, что все задачи должны решаться через DDD.

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, gandjustas, Вы писали:

I>>>Он говорит про программу проектирования печатных плат. Это означает набор определенных задач.
G>>Ага, только потом он сам признается что не понимает что есть "проектирование печатных плат" и дальше про задачи, решаемые программой, не заикается.
G>>Уж очень профессиональный подход...

I>А где взять программиста, который специалист по проектированию печетных плат ?
Так в том и дело что он не нужен. Надо чтобы программист мог разобраться не в радиотехнике, и не в проектировании печатных плат. Надо чтобы программист мог разобраться в том что нужно пользователю (этому самому специалисту по проектированию).

I>>>Далее он рассказывает про стуктуру модели на примере функции "прозванивание".
G>>Это он описывает модель, а не функцию системы. Как это ложится на функцию системы — непонятно.

I>Именно так — сначала разбирается с тем, что же ему надо делать.
Нет, он разбирается с тем как оно работает, заполняя тот самый пробел в знаниях за счет заказчика. А чтобы не перетруждать мозг строит "модель предметной области", те упрощенную формальную (возможно полуформальную) систему.

I>В такой области как у него с печатными платами как правило нет людей, которые умеют и программировать и ТЗ написать и задачи решать в терминах предметной области.
Да это и не является необходимым. Главное чтобы на человеческом языке объяснили каких результатов ждут и какие входные данные есть.

I>>>Диалог внимательно прочти "мы ищем долгие задержки сигнала...если путь прохождения сигнала слишком длинный...вычислить длину пути...переприем...прозванивание топологии..."
G>>Непонятно зачем это.
I>Это уточняется что же такое прозвон цепи.
Логично. Зачем уточняется, как этот прозвон будет выглядеть в программе? Будет ли он там вообще? Может он и не нужен инженерам.

I>>>Конечно. Сначала структура, потому что она важнее, а потом — функции, потому что для них нужны уже конкретные термины.
G>>Структура без функций никому не нужна. Структура является средством реализации функций.

I>Он от функций никуда не уходит. Диалог про проработку одной функции — прозванивание.
Конечно, потому что любая система ценна функциями, а не структурой.
Только выглядит это так: вот мы создали структуру, соответствующую предметной области заказчика, а теперь попытаемся натянуть на нее функции. Получилось — ура, не получилось — видимо мало используется исконно DDDшных паттернов: DTO, CQRS итп.

G>>А тут получается что эванс рисует структуру, даже без намека на функции. А потом из воздуха берет функции и они по счастливому стечению обстоятельств хорошо ложатся на функции.
I>Наоборот — ищет структуру для конкретной функции. Потом пишет, что то же самое было проделано под все функции. Читай диалог внимательно.
Прям по тексту: сначала структуры, потом функции.

I>>>Да, он и пишет — "ввели в обиход язык основаный на модели"
G>>Это далеко не самое главное.
I>Он с тобой не согласен.
Только он свое мнение никак не обосновывает.

I>>>Функции надо вычислить. Сначала челы выяснили, в чем заключается прозванивание цепи.
G>>А я так и не понял в чем оно заключается. Вот есть программа, которая делает "прозваниевание цепи". Как ей пользоваться? Что она вообще делает? Ты сможешь это объяснить по описанию эванса?

I>Программа может быть любая — серверная, десктоп, мобильная, веб-приложение. Что она делает — выполняет рассчеты определенные.
У разных типов программ даже юзкейсы разные, ты на одну модель не натянешь любой набор функций, так чтобы не пришлось менять эту модель.

I>>>Потом адаптировали под это дело модель
G>>То есть структура (модель) меняется в зависимости от функций? Тогда зачем столько усилий по созданию сначала структуры?

I>Конечно, структура будет меняться. Например был у тебя cost based design а понадобился еще и period based design — это изменение модели.
Непонятные для мня слова какие-то.

I>>>Эванс вообще все делает через рефакторинг и тестирование, то есть он не рожает готовые решения
G>>И что? То что он делает через тестирование делает его решение однозначно правильным? Как вообще понять что он делает то что нужно (то что приближает его к решению проблем\задач пользователей)?

I>>>Вот тебе такая функция — проектирование оптических сетей, cost based mesh design скажем для SONET.
G>>И?

I>Тебе ничего из этого непонятно, правда ?
Ага.

I>>>Валяй, пиши что ты из этого понял и как это приспособить к дизайну.
G>>Где требования\пожелания пользователей?
I>У меня этого почти никогда не было, за 10 лет
А как ты можешь узнать что ты вообще делаешь что-то полезное?
Или ты исключительно распилом бюджетов занимаешься?

G>>Это ты написал примерно как "создать графический редактор"... Вроде даже все знают что такое графический редактор, но такой постановки в принципе недостаточно чтобы даже начинать что-то делать.
I>Конечно. В этом вся фишка, когда нужно лезь куда то, кроме как "заказчик-заказ-позиция" или "фигуры", надо начинать с самых азов, т.е. с базовых понятий.
Зачем? Можешь обосновать такую точку зрения? Считаешь продуктивным изучать предметную область в отрыве от решаемых задач или наоборот считаешь полезным обучение кастомеров программированию?

I>Только потому, что кастомер часто вообще не имеет представления о программировании.
И что?

I>>>Если задачу прозванивания можно решить на предложеной структуре, значит структура подходящая для задачи прозванивания.
G>>То есть сначала таки надо получить набор задач, чтобы понять что конкретная структура подходит?
I>Конечно, кастомер должен хотя бы высказать, чего же он хочет. Наприер — рассчет прозвона.
Вот дальше его желания можно декомпозировать, по простой схеме. Любая программа состоит из трех частей: входные данные, алгоритм, выходные данные.
Входные данные надо как-то получить, выходные данные как-то сохранить и отобразить. Алгоритм же также декомпозируется, сначала с помощью пользователя, потому что он немного имеет представление с чем он работает, дальнейшая, более детальная, декомпозиция выполняется уже программистом. Сами данные тоже можно декомпозировать на более мелкие кусочки, чтобы адекватно представить связи (фактически нормальзовать до 3НФ), хотя не всегда это нужно и это уже будет понятно после того как будет тот самый набор функций.

Далее функции можно группировать. Например по общности входных данных, по общности выходных данных, по общности выполняемых действий.


G>>А если вдруг не подходит, то переделывать структуру?

I>Более того — переделывать постоянно, в т.ч. под конкретную задачу, как прозвон. Он ведь именно это и демонстрирует. А потом пишет, что все то же было проделано для всех функций.
То есть первоначальные изыскания по поводу структур нужны только чтобы восполнить пробел в знаниях проектировщика? Причем тут DDD тогда?

G>>Отличная статья на эту тему из соседнего вопроса.
I>Это не интересно. Фигуры всякие это для школьников.
Тем не менее многие взрослые дядьки такие же ошибки допускают. Например Буч со своими датчиками.

G>>Большинство бизнес-задач не являются задачами моделирования, и предложенным способом решаются плохо. Ту в книге не увидел обоснований что данный способ (DDD) хорошо подходит для других задач.
I>А он и не утверждает, что все задачи должны решаться через DDD.
Ну а какие должны?

Мы вот тут уже пытались выяснить где хорош DDD. Оказалось что для простых задач он не очень-то хорош, ибо вносит оверхед. А применимость для сложных задач не удалось пока никому доказать. Особенно не для задач моделирования.

Здравствуйте, gandjustas, Вы писали:

I>>А где взять программиста, который специалист по проектированию печетных плат ?
G>Так в том и дело что он не нужен. Надо чтобы программист мог разобраться не в радиотехнике, и не в проектировании печатных плат. Надо чтобы программист мог разобраться в том что нужно пользователю (этому самому специалисту по проектированию).

В другом форуме недавно видел твое сообщение старое, где ты рекомендуешь курить бухучет что бы писать софтину. Что же выходит, в бухучете надо разбираться, а в проектировании печатных плат не надо ?

I>>Именно так — сначала разбирается с тем, что же ему надо делать.
G>Нет, он разбирается с тем как оно работает, заполняя тот самый пробел в знаниях за счет заказчика. А чтобы не перетруждать мозг строит "модель предметной области", те упрощенную формальную (возможно полуформальную) систему.

Так и есть. Он вообще все делает за счет заказчика, в том числе и тесты и код пишет. Что тут странного ? Заказчик много знает, а модель хоть в каком виде представить не сможет хоть ты убейся.

I>>В такой области как у него с печатными платами как правило нет людей, которые умеют и программировать и ТЗ написать и задачи решать в терминах предметной области.
G>Да это и не является необходимым. Главное чтобы на человеческом языке объяснили каких результатов ждут и какие входные данные есть.

Он из них и вытягивал — см. диалог.

G>>>Непонятно зачем это.
I>>Это уточняется что же такое прозвон цепи.
G>Логично. Зачем уточняется, как этот прозвон будет выглядеть в программе? Будет ли он там вообще? Может он и не нужен инженерам.

Нужен. см. диалог. Специалист 2(по книге) говорит о том, для чего это надо.

I>>Он от функций никуда не уходит. Диалог про проработку одной функции — прозванивание.
G>Конечно, потому что любая система ценна функциями, а не структурой.

Это ничего не меняет. Что бы понять функции, нужно сначала вникнуть в область, понять все базовые понятия, термины, определения и тд и тд.

G>Только выглядит это так: вот мы создали структуру, соответствующую предметной области заказчика, а теперь попытаемся натянуть на нее функции.

"По мере того как инженеры описывали мне новые нужные им функции, я заставлял их проходить пошаговые сценарии взаимодействия объектов. Если объекты модель не справлялись с задачей прохождения алгоритма, мы вносили изменения. Мы улучшали модель и в месте с ней эволюционировал код"

По твоему это натягивать функции на модель ?

I>>Наоборот — ищет структуру для конкретной функции. Потом пишет, что то же самое было проделано под все функции. Читай диалог внимательно.
G>Прям по тексту: сначала структуры, потом функции.

Чушь. Диалог прочти то, там где речь про прозванивание.

I>>Он с тобой не согласен.
G>Только он свое мнение никак не обосновывает.

В первой главе — возможно.

I>>Программа может быть любая — серверная, десктоп, мобильная, веб-приложение. Что она делает — выполняет рассчеты определенные.
G>У разных типов программ даже юзкейсы разные, ты на одну модель не натянешь любой набор функций, так чтобы не пришлось менять эту модель.

Функции и не натягиваются. Модель под функции подбирается. Он и пишет, цитирую(лень набирать, кое что я опускаю) :

"В описаную модель внедрены знания о проектировании ПП, относящиеся непосредственно к решаемым задачам.... За педелами модели остались сотни фактов непосредтсвенно не относящихся к решаемым задачам, например фактические числовые характеристики компонентов."

"По мере того как инженеры описывали мне новые нужные им функции, я заставлял их проходить пошаговые сценарии взаимодействия объектов. Если объекты модель не справлялись с задачей прохождения алгоритма, мы вносили изменения. Мы улучшали модель и в месте с ней эволюционирвал код"

I>>Конечно, структура будет меняться. Например был у тебя cost based design а понадобился еще и period based design — это изменение модели.
G>Непонятные для мня слова какие-то.

Конечно непонятные. Ты хочешь функций, а надо начинать с терминов, определений и базовых понятий.

I>>Тебе ничего из этого непонятно, правда ?
G>Ага.

А я дал тебе пример функции, как ты просил. Теперь, что бы тебе стало понятно, что же за задача, мне нужно объяснить тебе все базовые понятия. И только потом ты сможешь говорить про функции.

I>>У меня этого почти никогда не было, за 10 лет
G>А как ты можешь узнать что ты вообще делаешь что-то полезное?

Выпытываю у людей, чего же они хотят и предлагаю решения. Иногда спеки таки бывают, но часто это ничего не означает.

I>>Конечно. В этом вся фишка, когда нужно лезь куда то, кроме как "заказчик-заказ-позиция" или "фигуры", надо начинать с самых азов, т.е. с базовых понятий.
G>Зачем? Можешь обосновать такую точку зрения? Считаешь продуктивным изучать предметную область в отрыве от решаемых задач или наоборот считаешь полезным обучение кастомеров программированию?

Предметная область изучается в контексте решаемых задач.

I>>Только потому, что кастомер часто вообще не имеет представления о программировании.
G>И что?

Он не может сформулировать задание толком.

G>Входные данные надо как-то получить, выходные данные как-то сохранить и отобразить. Алгоритм же также декомпозируется, сначала с помощью пользователя, потому что он немного имеет представление с чем он работает, дальнейшая, более детальная, декомпозиция выполняется уже программистом. Сами данные тоже можно декомпозировать на более мелкие кусочки, чтобы адекватно представить связи (фактически нормальзовать до 3НФ), хотя не всегда это нужно и это уже будет понятно после того как будет тот самый набор функций.

Эванс в книге именно это и демонстрирует.

I>>Более того — переделывать постоянно, в т.ч. под конкретную задачу, как прозвон. Он ведь именно это и демонстрирует. А потом пишет, что все то же было проделано для всех функций.
G>То есть первоначальные изыскания по поводу структур нужны только чтобы восполнить пробел в знаниях проектировщика? Причем тут DDD тогда?

При том, что ты никогда не будешь знать всей кухни и тебе нужно будет пополнять эти знания. Если ты займешься теми же печатными платами, то боюсь тебе времени на программирование не останется и так с любой другой областью.

I>>Это не интересно. Фигуры всякие это для школьников.
G>Тем не менее многие взрослые дядьки такие же ошибки допускают. Например Буч со своими датчиками.

Разве чьи то фигуры и датчики Буча говорят что либо про книгу Эванса ?

I>>А он и не утверждает, что все задачи должны решаться через DDD.
G>Ну а какие должны?

Я еще не прочел всю книгу

G>А применимость для сложных задач не удалось пока никому доказать. Особенно не для задач моделирования.

Что значит доказать применимость ?

В том же складском учете тебе нужно делать ровно то же, что делает Эванс в первом примере — предлагать модель и в терминах этой модели давать решение.

Просто модели бывают разными, вот и всё.

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, gandjustas, Вы писали:

I>>>А где взять программиста, который специалист по проектированию печетных плат ?
G>>Так в том и дело что он не нужен. Надо чтобы программист мог разобраться не в радиотехнике, и не в проектировании печатных плат. Надо чтобы программист мог разобраться в том что нужно пользователю (этому самому специалисту по проектированию).

I>В другом форуме недавно видел твое сообщение старое, где ты рекомендуешь курить бухучет что бы писать софтину. Что же выходит, в бухучете надо разбираться, а в проектировании печатных плат не надо ?
"Бухучет" это уже готовая модель вообще любого учета. Очень желательно не изобретать свои модели, а использовать то что проверено временем.

I>>>Именно так — сначала разбирается с тем, что же ему надо делать.
G>>Нет, он разбирается с тем как оно работает, заполняя тот самый пробел в знаниях за счет заказчика. А чтобы не перетруждать мозг строит "модель предметной области", те упрощенную формальную (возможно полуформальную) систему.

I>Так и есть. Он вообще все делает за счет заказчика, в том числе и тесты и код пишет. Что тут странного ? Заказчик много знает, а модель хоть в каком виде представить не сможет хоть ты убейся.
Так пусть заказчик оплатит обучение на ускоренных курсах инженеров печатных плат. Вообще заказчик обычно платит за решение своих проблем, а не решение проблем разработчиков ПО.

I>>>Он от функций никуда не уходит. Диалог про проработку одной функции — прозванивание.
G>>Конечно, потому что любая система ценна функциями, а не структурой.
I>Это ничего не меняет. Что бы понять функции, нужно сначала вникнуть в область, понять все базовые понятия, термины, определения и тд и тд.
Такс, уже пошли по кругу... Я вот утверждаю что не надо "вникать", чаще всего достаточно того что сообщает потенциальный пользователь. А если "бизнес" заказчика сложен, то появляется дополнительный слой аналитиков, которые могут рассказать это все гораздо лучше.

G>>Только выглядит это так: вот мы создали структуру, соответствующую предметной области заказчика, а теперь попытаемся натянуть на нее функции.

I>"По мере того как инженеры описывали мне новые нужные им функции, я заставлял их проходить пошаговые сценарии взаимодействия объектов. Если объекты модель не справлялись с задачей прохождения алгоритма, мы вносили изменения. Мы улучшали модель и в месте с ней эволюционировал код"

I>По твоему это натягивать функции на модель ?
Именно, зачем было заранее создавать модель, тем более в коде. Любой написанный код стоит денег и ограничивает "пространство маневра". Лучше код не писать, или писать такой чтобы его без проблем можно было выкинуть. Всеобъемлющая Domain Model как раз полная противоположность.

I>>>Наоборот — ищет структуру для конкретной функции. Потом пишет, что то же самое было проделано под все функции. Читай диалог внимательно.
G>>Прям по тексту: сначала структуры, потом функции.
I>Чушь. Диалог прочти то, там где речь про прозванивание.
А до прозванивания что? Там же тоже диалоги есть.

I>>>Он с тобой не согласен.
G>>Только он свое мнение никак не обосновывает.
I>В первой главе — возможно.
А в последующих тем более. Там он технические аспекты рассматривает в основном.

I>>>Программа может быть любая — серверная, десктоп, мобильная, веб-приложение. Что она делает — выполняет рассчеты определенные.
G>>У разных типов программ даже юзкейсы разные, ты на одну модель не натянешь любой набор функций, так чтобы не пришлось менять эту модель.
I>Функции и не натягиваются. Модель под функции подбирается. Он и пишет, цитирую(лень набирать, кое что я опускаю) :
I>"В описаную модель внедрены знания о проектировании ПП, относящиеся непосредственно к решаемым задачам.... За педелами модели остались сотни фактов непосредтсвенно не относящихся к решаемым задачам, например фактические числовые характеристики компонентов."
Да я не против, пусть модель создают. Но эванс пытается модель создавать опираясь не на функции, а на "предметную область" (1), реализовывать модель в коде в виде классов с "поведением", называемых domain model (2).

I>>>Конечно, структура будет меняться. Например был у тебя cost based design а понадобился еще и period based design — это изменение модели.
G>>Непонятные для мня слова какие-то.
I>Конечно непонятные. Ты хочешь функций, а надо начинать с терминов, определений и базовых понятий.
Не нужно. Скажи что на входе, что на выходе и как оно преобразуется (на пальцах).

I>>>Тебе ничего из этого непонятно, правда ?
G>>Ага.

I>А я дал тебе пример функции, как ты просил. Теперь, что бы тебе стало понятно, что же за задача, мне нужно объяснить тебе все базовые понятия. И только потом ты сможешь говорить про функции.
Ты не дал пример функции, ты назвал несколько непонятных слов из непонятной же предметной области.
Ты как пользователь программы человеческим языком можешь сказать что ты хочешь получить\увидеть?

I>>>У меня этого почти никогда не было, за 10 лет
G>>А как ты можешь узнать что ты вообще делаешь что-то полезное?

I>Выпытываю у людей, чего же они хотят и предлагаю решения. Иногда спеки таки бывают, но часто это ничего не означает.
То есть тыки собираешь требования\пожелания пользователей?



I>>>Только потому, что кастомер часто вообще не имеет представления о программировании.
G>>И что?
I>Он не может сформулировать задание толком.
А ему не надо формулировать задание, ему надо свои пожелания сказать.

G>>Входные данные надо как-то получить, выходные данные как-то сохранить и отобразить. Алгоритм же также декомпозируется, сначала с помощью пользователя, потому что он немного имеет представление с чем он работает, дальнейшая, более детальная, декомпозиция выполняется уже программистом. Сами данные тоже можно декомпозировать на более мелкие кусочки, чтобы адекватно представить связи (фактически нормальзовать до 3НФ), хотя не всегда это нужно и это уже будет понятно после того как будет тот самый набор функций.
I>Эванс в книге именно это и демонстрирует.
Ага, только в обратном порядке

I>>>Это не интересно. Фигуры всякие это для школьников.
G>>Тем не менее многие взрослые дядьки такие же ошибки допускают. Например Буч со своими датчиками.
I>Разве чьи то фигуры и датчики Буча говорят что либо про книгу Эванса ?
Это мы от темы отошли, эванс не при чем.

I>>>А он и не утверждает, что все задачи должны решаться через DDD.
G>>Ну а какие должны?
I>Я еще не прочел всю книгу
А я два раза прочел, нету там. Чем дальше тем неинтереснее. У меня осталось ощущение что меня кинули, так как ответов на "вопрос почему стоит использовать DDD" я не нашел.

G>>А применимость для сложных задач не удалось пока никому доказать. Особенно не для задач моделирования.
I>Что значит доказать применимость ?
Доказать что некоторых подход дает преимущество по сравнению с другими подходами.

I>В том же складском учете тебе нужно делать ровно то же, что делает Эванс в первом примере — предлагать модель и в терминах этой модели давать решение.
Когда модель давно существует и её применимость доказана это одно. А когда кто-нить просто выдумывает эту модель — совсем другое.

I>Просто модели бывают разными, вот и всё.
В первую очередь задачи бывают разными. Я вот недавно сталкивался с тремя вариантами задач составления расписаний. Но учитывая что в разных прогараммах расписания с разными целями использовались получились совершенно непохожие друг на друга куски кода.

Здравствуйте, gandjustas, Вы писали:

I>>В другом форуме недавно видел твое сообщение старое, где ты рекомендуешь курить бухучет что бы писать софтину. Что же выходит, в бухучете надо разбираться, а в проектировании печатных плат не надо ?
G>"Бухучет" это уже готовая модель вообще любого учета. Очень желательно не изобретать свои модели, а использовать то что проверено временем.

А где взять готовую для любой другой области ? А между тем Эванс отвечает именно на этот вопрос.

I>>Так и есть. Он вообще все делает за счет заказчика, в том числе и тесты и код пишет. Что тут странного ? Заказчик много знает, а модель хоть в каком виде представить не сможет хоть ты убейся.
G>Так пусть заказчик оплатит обучение на ускоренных курсах инженеров печатных плат. Вообще заказчик обычно платит за решение своих проблем, а не решение проблем разработчиков ПО.

Он платит за всё вообще говоря, без его задач у девелоперов никаких проблем нет. На ускореных курсах будет много лишнего материала, а нужен только тот что необходим для конкретного перечня задач.

I>>Это ничего не меняет. Что бы понять функции, нужно сначала вникнуть в область, понять все базовые понятия, термины, определения и тд и тд.
G>Такс, уже пошли по кругу... Я вот утверждаю что не надо "вникать", чаще всего достаточно того что сообщает потенциальный пользователь. А если "бизнес" заказчика сложен, то появляется дополнительный слой аналитиков, которые могут рассказать это все гораздо лучше.

Эванс отвечает и на этот вопрос

I>>По твоему это натягивать функции на модель ?
G>Именно, зачем было заранее создавать модель, тем более в коде. Любой написанный код стоит денег и ограничивает "пространство маневра". Лучше код не писать, или писать такой чтобы его без проблем можно было выкинуть. Всеобъемлющая Domain Model как раз полная противоположность.

А где ты увидел что он заранее модель в коде создаёт ? Скажи номер страницы

I>>Чушь. Диалог прочти то, там где речь про прозванивание.
G>А до прозванивания что? Там же тоже диалоги есть.

Цитирую "По мере обсуждения того, что должна делать программа я начал рисовать схемы сам"

I>>В первой главе — возможно.
G>А в последующих тем более. Там он технические аспекты рассматривает в основном.

Не согласен. Ты книгу читаешь или отрывки в интернете ищешь ?

I>>"В описаную модель внедрены знания о проектировании ПП, относящиеся непосредственно к решаемым задачам.... За педелами модели остались сотни фактов непосредтсвенно не относящихся к решаемым задачам, например фактические числовые характеристики компонентов."
G>Да я не против, пусть модель создают. Но эванс пытается модель создавать опираясь не на функции, а на "предметную область" (1), реализовывать модель в коде в виде классов с "поведением", называемых domain model (2).

Функции никуда не деваются. Я же цитировал. Еще раз что ли процитировать ?

I>>Конечно непонятные. Ты хочешь функций, а надо начинать с терминов, определений и базовых понятий.
G>Не нужно. Скажи что на входе, что на выходе и как оно преобразуется (на пальцах).

Что бы описать входы и выходы, ужны термины, определения, базовые понятия.

I>>А я дал тебе пример функции, как ты просил. Теперь, что бы тебе стало понятно, что же за задача, мне нужно объяснить тебе все базовые понятия. И только потом ты сможешь говорить про функции.
G> Ты не дал пример функции, ты назвал несколько непонятных слов из непонятной же предметной области.

Я дал пример именно функции, так как кё понимают кастомеры.

G>Ты как пользователь программы человеческим языком можешь сказать что ты хочешь получить\увидеть?

Все пользователи имеют специальное инженерное образование в области телекоммуникаций и программировать считай не умеют.

I>>Выпытываю у людей, чего же они хотят и предлагаю решения. Иногда спеки таки бывают, но часто это ничего не означает.
G>То есть тыки собираешь требования\пожелания пользователей?

Я уточнаю все требования после того, как получаю огрызок который называется спецификацией а иногда и помогаю спецификацию наколбасить. Бывает спеки хорошие приходят, но такое на моей памяти было два раза и только один раз из этих двух код пошел в продакшн.

I>>Он не может сформулировать задание толком.
G>А ему не надо формулировать задание, ему надо свои пожелания сказать.

В каком виде ты хочешь пожелания ? Ты хоть пример покажи.

G>>>Входные данные надо как-то получить, выходные данные как-то сохранить и отобразить. Алгоритм же также декомпозируется, сначала с помощью пользователя, потому что он немного имеет представление с чем он работает, дальнейшая, более детальная, декомпозиция выполняется уже программистом. Сами данные тоже можно декомпозировать на более мелкие кусочки, чтобы адекватно представить связи (фактически нормальзовать до 3НФ), хотя не всегда это нужно и это уже будет понятно после того как будет тот самый набор функций.
I>>Эванс в книге именно это и демонстрирует.
G>Ага, только в обратном порядке

Этот обратный порядок на самом деле прямой. Это с бухучетом или фигурами ты можешь писать сверху вниз, потому что в основном ве наперед известно.

I>>Что значит доказать применимость ?
G>Доказать что некоторых подход дает преимущество по сравнению с другими подходами.

Ну так это книгой не докажешь.

I>>В том же складском учете тебе нужно делать ровно то же, что делает Эванс в первом примере — предлагать модель и в терминах этой модели давать решение.
G>Когда модель давно существует и её применимость доказана это одно. А когда кто-нить просто выдумывает эту модель — совсем другое.

Разумеется. Если ты создаешь модель, главное что бы она позволяла задачи решать и могла эволюционировать. Потом можно и функциональный дизайн вывести, но начать с этого когда ты не знаешь области просто невозможно.

G>В первую очередь задачи бывают разными.

А еще бывает много задач в одной программе, а модель будет одна.

Здравствуйте, Ikemefula, Вы писали:

Хммм... может это обсуждение в отдельную ветку вынести? А то топикстартера щас окончательно запутаем

Или вообще закрыть — спорить можно до бесконечности, каждый в книжках видит исключительно своё и остальных слушать не желает категорически

Здравствуйте, perekrestov, Вы писали:
P>Я хотел показать следущее. Вот если Entity понадобится взаимодействовать с упомянутым вами сервисом.


P>Тогда как эта сущность должна получать на него ссылку?
У меня эта сущность не будет взаимодействие с таким сервисом.

P>Например, при покупке товара ГолдКастомером ему начисляется скидка, бонусы или что-то в этом роде.
А ещё делается уведомление по почте покупателю и покупатель регистрируется у партнёров портала .


P>

P>Customer customer;
P>// тут получили ссылку на него каким-то образом.

P>Product p;
P>// получили ссылку на товар

P>customer.Buy(p);
P>

P>(пример с покупкой я вытянул с головы).
У вас слой служб перемешивается с сущностями, что не очень здорово. Я бы сделал

  interface IPayementService 
  {
       void Buy(Customer buyer, Product product);
  }

Альтернативный вариант — доменные события здесь. В этом случае метод Customer.Buy генерирует событие ProductBoughtEvent { Buyer, Product }. Подписчик на это событие делает всю нетривиальную логику, связанную с БД, взаимодействием с внешними службами и т.д.


P>У меня сложилось такое ощущение, что многие пытаются выносить более-мение сложную логику в бизнес сервисы из сущностей, т.к.
P>Но ведь это приводит к анимичной модели... А хочется все-таки понять как добиться на практике того, о чем говорит Эванс.
Книга Эванса достаточно абстрактная штука, нельзя её воспринимать буквально. Лучше почитайте современные блоги, статьи по DDD.

Здравствуйте, Aviator, Вы писали:

A>Здравствуйте, perekrestov, Вы писали:
P>>Я хотел показать следущее. Вот если Entity понадобится взаимодействовать с упомянутым вами сервисом.


P>>Тогда как эта сущность должна получать на него ссылку?
A>У меня эта сущность не будет взаимодействие с таким сервисом.

P>>Например, при покупке товара ГолдКастомером ему начисляется скидка, бонусы или что-то в этом роде.
A>А ещё делается уведомление по почте покупателю и покупатель регистрируется у партнёров портала .


P>>

P>>Customer customer;
P>>// тут получили ссылку на него каким-то образом.

P>>Product p;
P>>// получили ссылку на товар

P>>customer.Buy(p);
P>>

P>>(пример с покупкой я вытянул с головы).
A>У вас слой служб перемешивается с сущностями, что не очень здорово. Я бы сделал
A>

A>  interface IPayementService 
A>  {
A>       void Buy(Customer buyer, Product product);
A>  }
A>

А еще лучше иметь интерфейс

interface IPayementService 
{
     void Buy(int cutomerId, int productId);
}

A>Альтернативный вариант — доменные события здесь. В этом случае метод Customer.Buy генерирует событие ProductBoughtEvent { Buyer, Product }. Подписчик на это событие делает всю нетривиальную логику, связанную с БД, взаимодействием с внешними службами и т.д.

Было смешивание слоя служб и сущностей, а стало смешение инфраструктуры и сущностей.

Здравствуйте, Aviator, Вы писали:

A>Здравствуйте, perekrestov, Вы писали:
P>>Я хотел показать следущее. Вот если Entity понадобится взаимодействовать с упомянутым вами сервисом.


P>>Тогда как эта сущность должна получать на него ссылку?
A>У меня эта сущность не будет взаимодействие с таким сервисом.

P>>Например, при покупке товара ГолдКастомером ему начисляется скидка, бонусы или что-то в этом роде.
A>А ещё делается уведомление по почте покупателю и покупатель регистрируется у партнёров портала .

A>Альтернативный вариант — доменные события здесь. В этом случае метод Customer.Buy генерирует событие ProductBoughtEvent { Buyer, Product }. Подписчик на это событие делает всю нетривиальную логику, связанную с БД, взаимодействием с внешними службами и т.д.
Я также о них думал....
В той статье, на которую я раньше ссылался, автор, вообще, советует, что если у нас логика затрагивает более одной сущности (даже не aggregate root), то нужно выносить
эту логику в бизнес-сервис. Но, как я понял, инъекция в Domain Objects вполне приемлимый вариант.
BTW, Довольно редко я видел, чтобы более-менее сложная логика затрагивала только одну сущность. Следуя этой логике мы будем иметь bloated services, что также не очень хорошо.
У меня от всего этого голова кругом идет.
Из всего, что я прочитал, я понял что следует находить компромис: максимально всю логику домена помещать в сущности, но если не можем туда ее поместить, то помещаем в сервисы.

Здравствуйте, Aviator, Вы писали:

A>Здравствуйте, perekrestov, Вы писали:

P>>Здравствуйте, Aviator, Вы писали:



P>>In the sample application, the service object (FundingServiceImpl) uses DI to inject the Entity objects (Loan, Borrower and FundingRequest). Also, Entities reference Repositories via DI. Similarly, other Java EE resources like DataSource, Hibernate Session Factory and Transaction Manager are injected into Service and Repository objects.
P>>[/q]
A>Помещать доступ к данным, даже через интерфейс в доменный объект ... В итоге получаем огромные сущности с набором данных и кучей логики внутри. Не забываем кстати, что логика меняется чаще данных. И вообще, если очень хочется, что бы триггером начала обработки был вызов метода доменного объекта, то тогда уж domain events. А если по простому, то сложные действия лучше делать через набор служб, которые переколбасят доменные объекты как нужно.
Возникают у меня сомнения, что данные нужно отделять от поведения, даже несмотря на упомянутую вами разницу в жизненных циклах данных и поведения.

Данные все-таки у вас в сторадже хранятся. Они как хранились так и будут храниться.
А модель, которая изменяется и должна уметь изменяться, и которую вы постоянно совершенствуете является моделью реального мира (если так ее можно назвать).
Соотв., я пока не увидел причин отделять поведение от сущностей, т.к. сущности это еще не сами данные. Да мы их маппим на данные (ORM), но это еще не повод "цементировать" их
и делать, так сказать "readonly".

А нет ли у вас полезных ссылок на статьи о DDD. Уж очень хочется разобраться

Спасибо.

Здравствуйте, gandjustas, Вы писали:
P>>>(пример с покупкой я вытянул с головы).
A>>У вас слой служб перемешивается с сущностями, что не очень здорово. Я бы сделал
A>>

A>>  interface IPayementService 
A>>  {
A>>       void Buy(Customer buyer, Product product);
A>>  }
A>>

G>А еще лучше иметь интерфейс

G>

G>interface IPayementService 
G>{
G>     void Buy(int cutomerId, int productId);
G>}
G>

Это уже на другом уровне.

A>>Альтернативный вариант — доменные события здесь. В этом случае метод Customer.Buy генерирует событие ProductBoughtEvent { Buyer, Product }. Подписчик на это событие делает всю нетривиальную логику, связанную с БД, взаимодействием с внешними службами и т.д.

G>Было смешивание слоя служб и сущностей, а стало смешение инфраструктуры и сущностей.
Да, но службы и сущности плодятся и меняются. А брокер один и меняется редко. Собственно это вопрос компромисса, идеального решения нет.

Здравствуйте, gandjustas, Вы писали:

G>Так не стоит делать. Эванс мягко говоря обманывает. Если посмотреть примеры приложений в стиле DDD, то там всегда существует некоторый слой, где данные отделены от методов.

А можете привести примеры? поглядеть хочется.)

Здравствуйте, michael_isu, Вы писали:

_>Здравствуйте, gandjustas, Вы писали:

G>>Так не стоит делать. Эванс мягко говоря обманывает. Если посмотреть примеры приложений в стиле DDD, то там всегда существует некоторый слой, где данные отделены от методов.

_>А можете привести примеры? поглядеть хочется.)

http://dddsample.sourceforge.net/