7й подкаст Петербургской группы ALT.NET

Domain-Driven Design и CQRS

Ведущий: butaji

Наши гости: frozen_space и chaliy

Содержание:

  • Что значат все эти буквы, стоит ли изучать?
  • Список литературы

Applying Domain-Driven Design and Patterns: With Examples in C# and .NET http://www.amazon.com/Applying-Domain-Driven-Design-Patterns-Examples/dp/0321268202

Yahoo group Domain-Driven Design http://tech.groups.yahoo.com/group/domaindrivendesign/

http://www.infoq.com/minibooks/domain-driven-design-quickly

http://www.domaindrivendesign.org/

CQRS à la Greg Young http://blog.fohjin.com/blog/2009/11/12/CQRS_a_la_Greg_Young

  • Насколько DDD реально имеет место в проектах?
  • Действительно ли DDD помогает управлять сложностью?
  • Сколько паттернов вы запомнили из книги Ивенса?
  • CQRS — недостаAтки и преимущества
  • OpenSource примеры

DDDSample http://dddsample.sourceforge.net/

S#arp Architecture http://code.google.com/p/sharp-architecture/

http://www.codeplex.com/dddpds

http://www.habanerolabs.com/

RSS-поток подкастов

Реклама

Полноценный Behavior Driven Development на .NET

Введение

Меня переполняют эмоции. Это связанно с тем, что сегодня мой товарищ сообщил о следующем: есть полноценная реализация BDD движка для .NET.

Называется проект SpecFlow

Исходный код ныне базируется на GitHub http://github.com/techtalk/SpecFlow

Немного теории

Вопрос о том, что же такое Behavior Driven Development неоднозначен. Особенно противоречивы его отношения с Test Driven Development. Однако предлагаю абстрагироваться от сравнения двух подходов и договорится, что суть этого есть одно и тоже, т.к. особенных различий нет. Основной чертой выделяющей BDD от TDD по-моему усмотрению является ориентация на различных участников процесса производства программного обеспечения, будь то менеджер, разработчик, тестер, заказчик. Вы вместе пишете тесты, и вместе можете развивать проект в нужном направлении и вполне понятных терминах. Так же на ум в данном случае приходит такой термин, как Ubiquitous Language из Domain Driven Design. А ведь и в самом деле, обобщение терминологии описания вашей предметной области вполне может ложится на практику BDD.

Меня в BDD больше всего прельщает возможность описания функциональности на разговорном языке, что гарантирует актуальность документации (т.к. ваши behavior тесты и будут фактически вашей документацией). Так же при написании тестов на подобном уровне вы четко сконцентрированы на поставленной задаче, а не способах её разрешения и применяемых инструментах, что так же весьма полезно для качества как вашего дизайна, так и соответствии программного продукта назначению.

Все известные инструменты (к примеру mock-объекты) и практики (такие как шаблоны тестирования), используемые вами при разработке в стиле TDD, изменятся незначительно при переходе на BDD стиль, в связи с чем можно начать применять BDD уже сегодня. Так же вполне возможно, что вам необходимо будет произвести более низкоуровневое тестирование некоторых компонентов, что несомненно приведёт к смешиванию двух практик, что несомненно должно происходить осознано и с должен вниманием.

Снаружи вовнутрь. Процесс при разработке в стиле BDD так же немного смещается. Так как тестами двигают в равной мере все участники, то ориентация в первую очередь будет на интерфейсе пользователя. т.е. для описания необходимых фич, заинтересованным лицам (скорее всего заказчику) необходимо будет держать перед глазами эскизы эрканов для взаимодействия. Этот подход снижает риски неоправданных ожиданий, т.к. в большинстве случаев программный продукт для потребителя – всего лишь пользовательский интерфейс.

Инструменты

cuke_logo[1] На данный момент существует множество BDD framework’ов, однако “наиболее верным” с точки зрения родоначальников данного термина (Dan North, David Chelimsky, Aslak Hellesøy) является такой проект как: Cucumber (ранее известный как RSpec). Этот проект написан для Ruby. Большинство RubyOnRails разработчиков (как основные представители ruby сообщества) пользуются именно этим фреймворком для тестирования своих продуктов.

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

Инструменты для .NET в основном копируют формат и принципы, заложенные в Cucumber, их существует несколько:

  • SpecFlow – предмет сегодняшнего разговора (из плюсов – аналогия с Cucumber и интеграция в Visual Studio 2008 и 2010)
  • NBehave – работа с данным фреймворком близка к возможностям Cucumber в настоящее время (до этого он так же был в разряде “многословных” и  это, наверное, наиболее распространенный BDD фреймворк среди .NET разработчиков)
  • NSpecify, NSpec – довольно-таки “многословные” фреймворки для BDD
  • Specter – аналогично, примечателен тем, что написан на Boo

Теперь практика

Для того, чтобы проиграться с этим замечательным инструментом нам понадобятся:

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

Создавать мы с вами будет стандартный пример для подобного рода фреймвороков, а именно Калькулятор.image

Создадим новый solution в студии, в котором будет два проекта.

  1. Calculator
  2. Calculator.Tests

Для того, чтобы его описать в решении + подготовить реализацию нам понадобится немного инфраструктурных заморочек в проекте Calculator.Tests (ниже работа пока будет только с ним):

  • добавить reference на TechTalk.SpecFlow.dll (которая скорее всего окажется в папке с установленным SpecFlow)
  • добавить reference на nunit.framework.dll (его следует искать в GAC’е)

Теперь всё готово для того, чтобы погрузиться в мир BDD. Откиньтесь на спинки кресел и расстегните ремни.

В пункте Add New Item у вас наверняка появились новые пункты, начинающиеся на SpecFlowimage

Далее задайте имя нашей фиче addition.feature и щелкните Add.

Как вы догадались мы добавим описание первой фичи, для этого тот текст, который будет содержаться в файле по-умолчанию следует заменить на следующий:

http://github.com/aslakhellesoy/cucumber/blob/master/examples/i18n/en/features/addition.feature# language: en

Feature: Addition

  In order to avoid silly mistakes

  As a math idiot 

  I want to be told the sum of two numbers

  Scenario Outline: Add two numbers

    Given I have entered <input_1> into the calculator

    And I have entered <input_2> into the calculator

    When I press <button>

    Then the result should be <output> on the screen

  Examples:

    | input_1 | input_2 | button | output |

    | 20      | 30      | add    | 50     |

    | 2       | 5       | add    | 7      |

    | 0       | 40      | add    | 40     |

Жмём ctrl+s и большая часть работы по описанию выполнена.

Теперь нам надо сделать описание steps, для того, чтобы связать сценарий с тестируемым модулем. Для этого добавьте новый элемент SpecFlow Step Definition, назовём мы его calculator_steps.cs.

Данный файл уже содержит в себе некоторые записи по-умолчанию, в принципе они вполне подходят для нашего примера. (Кстати, обратите внимание как строго упорядочены все методы по шаблону AAA: Arrange, Act, Assert, в данной интерпретации Given, When, Then)

Однако немного их всё же придется изменить.

Внутри данного метода:

[Given("I have entered (.*) into the calculator")]
public void GivenIHaveEnteredSomethingIntoTheCalculator(int number)
{
  //TODO: implement arrange (recondition) logic
  // For storing and retrieving scenario-specific data,
  // the instance fields of the class or the
  //     ScenarioContext.Current
  // collection can be used.
  // To use the multiline text or the table argument of the scenario,
  // additional string/Table parameters can be defined on the step definition
  // method.

  ScenarioContext.Current.Pending();
}

Мы видим, что на нашем калькуляторе печатают некоторые числа, ок, подтвердим это:

[Given("I have entered (.*) into the calculator")]
public void GivenIHaveEnteredSomethingIntoTheCalculator(int number)
{
    Calculator.Input(number);

}

И не стесняйтесь того, что пока Visual Studio не совсем понимает, что такое Calculator 😉

Отлично, смотрим на следующий метод, его мы тоже немного поправим:

[When("I press add")]
public void WhenIPressAdd()
{

    Calculator.Add();

}

И, вслед за ним, удостоверимся, что получаем именно то, чего желаем:

[Then("the result should be (.*) on the screen")]
public void ThenTheResultShouldBe(int result)
{
    Assert.IsEqual(result, Calculator.Result);
}

Теперь самое время разобраться с нашим калькулятором.

Создадим следующее поле:

protected Calculator Calculator = new Calculator();

Теперь пора бы разобраться и с типом Calculator, его мы создадим в проекте Calculator. Так же добавим reference из проекта Calculator.Tests на проект Calculator. С типом так же всё в порядке, однако не хватает некоторых методов, их тоже следует создать.

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

image

Теперь можно заняться имплементацией нашего калькулятора. На данный момент я предлагаю следующее:

public class Calculator
{
  private IList<int> _buffer = new List<int>();

  public int Result { get; private set; }

  public void Input(int number)
  {
    _buffer.Add(number);
  }

  public void Add()
  {
    Result = _buffer.Sum();
    _buffer.Clear();
  }

}

Запускаем наши тесты и видим, что они проходят, супер!

image

Вроде бы с первой фичей мы успешно разобрались, почему бы не взяться за вторую?

Второй возможностью будет деление:

http://github.com/aslakhellesoy/cucumber/blob/master/examples/i18n/en/features/division.feature

# language: en

Feature: Division

  In order to avoid silly mistakes

  Cashiers must be able to calculate a fraction

  Scenario: Regular numbers

    Given I have entered 3 into the calculator

    And I have entered 2 into the calculator

    When I press divide

    Then the result should be 1.5 on the screen

*в оригинале для cucumber у aslakhellesoy несколько иной синтаксис, но он на данный момент не поддерживается в SpecFlow

данную фичу мы добавим в наш тестовый проект под названием devision.feature. как не трудно заметить, что основные шаги мы с вами уже описали в предыдущем примере, сейчас осталось только добавить 1 метод:

[When("I press divide")]
public void WhenIPressDevide()
{
  Calculator.Devide();
}

Добавить так же метод в класс Calculator.

Скомпилировать наш проект. И запустить тесты. Конечно же они не пройдут, т.к. деление мы с вами ещё не реализовали:

public void Devide()
{
  Result = _buffer[0] / _buffer[1];
  _buffer.Clear();
}

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

Материалы

Исходный код рассматриваемого проекта http://dl.dropbox.com/u/4070949/Calculator.zip

Скринкаст от создателей SpecFlow http://www.specflow.org/specflow/screencast.aspx

Моя статья Пример практики BDD при работе со Specter Framework

Книга The RSpec Book: Behaviour Driven Development with RSpec, Cucumber, and Friends

Википедия http://en.wikipedia.org/wiki/Behavior_Driven_Development


Вы подготовились к приходу AutoMapper?

Введение

Данная статья предназначена к прочтению разработчикам и архитекторам распределенных систем на платформе .NET. В ней будет рассмотрен гибкий каркас для объектно-объектного преобразования (далее маппинга). Так же будут рассмотрены некоторые аспекты Domain-Driven Design’а.

Зачем мне нужен объектно-объектный маппинг?

Следуя основным принципам DDD, мы реализуем так называемую Rich Domain Model (эти объекты также должны соответствовать принципу POxO). Объекты реального мира, нашедшие отражение в нашем приложении частенько так же передают достаточную сложность, следовательно, достаточно корректно построенная модель крайне тяжело поддаётся перемещению между слоями приложения (не путать с легкостью вносимых изменений).

Data Transfer Object Тем не менее достаточно часто появляется необходимость “распределения” (я имею ввиду создание промежуточных сущностей, а не растекание модели по слоям) модели между слоями, для отображения, к примеру, атрибутов её сущностей пользователям (в шаблонах представления MVx), а так же передаче по сервисам (Data Transfer Object). Порой бывает даже, что модель “распределяется” для тестирования некоторых аспектов.

Предположим, мы в Африке, у нас банановая плантация, всё классно, выращиваем, продаём, выращиваем, продаём, но тут внезапно внутренний рынок переполняется и нам надо расширятся (к примеру вести бананы в Россию), мы пишем WCF сервис, который будет слать наши бананы. Так как бананы в Африке имеют несколько иное значение, чем в России, то, соответственно нам понадобятся лишь некоторые атрибуты (остальные фактически не имеют значения), которые мы забубеним в наш DTO

Правильнее было бы дать классу BananaWrapper название BananaDTO, для того, чтобы точно отображать его функциональное назначение, но я оставлю название таким для большего уровня абстракции, к примеру, если нам понадобится сделать автомат по продажи бананов и поместить этот объект в Presenter Model

Хочу заметить, что порой задача преобразования объектов становится довольно-таки нетривиальной и в лучшем случаем выглядит примерно подобным образом (это решение в лоб, есть ещё более изощренные методы ;)):

  1. public class Banana
  2. {
  3. public string Country { get; set; }
  4. public double Price { get; set; }
  5. public int Age { get; set; }
  6. }
  7. public class BananaWrapper
  8. {
  9. public string Country { get; set; }
  10. public double Price { get; set; }
  11. public int Age { get; set; }
  12. }
  13. public class BananaMapper
  14. {
  15. public BananaWrapper GetWrapper(Banana banana)
  16. {
  17. return new BananaWrapper
  18. {
  19. Country = banana.Country,
  20. Price = banana.Price,
  21. Age = banana.Age
  22. };
  23. }
  24. }

* This source code was highlighted with Source Code Highlighter.

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

AutoMapper

И тут на сцену выходит наш персонаж – AutoMapper, и сразу же говорит мне: — послушай, ты что такое пишешь? тебе не лень? ты не боишься допустить ошибок? хочешь я тебе помогу?!. Я конечно же соглашаюсь, и получаю в ответ следующее решение моей проблемы:

  1. public class BananaMapper
  2. {
  3. public BananaMapper()
  4. {
  5. Mapper.CreateMap<Banana, BananaWrapper>();
  6. }
  7. public BananaWrapper GetWrapper(Banana banana)
  8. {
  9. return Mapper.Map<Banana, BananaWrapper>(banana); ;
  10. }
  11. }

* This source code was highlighted with Source Code Highlighter.

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

Итак, что же за механизмы лежат внутри AutoMapper?

AutoMapper проверяет есть соответствующие поля в указанных типах, соответствие проводится как по имени свойства, так и по его типу. Даже такие нюансы, как Product.Name и ProductName будут учтены и обработаны автоматически (wow!). Плюс ко всему методы GetXXX() будут ложится на свойства XXX (да, ну и естественно для особо раздражительных все эти прелести можно отключить и переопределить всё в своих собственных таблицах соответствия (далее мапках)).

Кастомная конфигурация выглядит примерно следующим образом:

  1. Mapper.CreateMap<CalendarEvent, CalendarEventForm>()
  2. .ForMember(dest => dest.EventDate, opt => opt.MapFrom(src => src.EventDate.Date))
  3. .ForMember(dest => dest.EventHour, opt => opt.MapFrom(src => src.EventDate.Hour))
  4. .ForMember(dest => dest.EventMinute, opt => opt.MapFrom(src => src.EventDate.Minute));

* This source code was highlighted with Source Code Highlighter.

Кстати, все ваши кастомные конфигурации легко поддаются проверке с помощью следующего метода:

  1. Mapper.AssertConfigurationIsValid();

* This source code was highlighted with Source Code Highlighter.

Так же не плохо работает с:

История

Проект появился в конце’08-начале’09, около полугода находился в версии 0.31, сейчас же добрался до RC 1.0, думаю, что релиз уже совсем скоро.

Overhead?

banana Дебаты по поводу того, насколько быстрее будет работать AutoMapper и присвоение свойств в ручную (и прочие мульки) я игнорирую, т.к. готов пойти на любые жертвы производительности, если получу ясный, читабельный код. Ах, да, автор AutoMapper позаботился об этих вопросах и написал бенчмарки, смотреть здесь: http://code.google.com/p/automapperhome/source/browse/#svn/trunk/src/Benchmark

Ресурсы

Скачать проект, а так же ознакомиться с исходными кодами можно здесь: http://code.google.com/p/automapperhome/

Обсуждения каркаса здесь: http://groups.google.com/group/automapper-users

Так же примеры использования есть здесь: http://automapper.codeplex.com/

Кстати проект разрабатывает Jimmy Bogard, который так же пишет BDD фреймворк для .NET под названием NBehave.


Учимся проектировать на основе предметной области (DDD: Domain Driven Design)

1. Введение

В данной статье я хотел бы рассказать об этих трёх буквах, постоянно находящихся на слуху, но для многих являющихся тайной за семью печатями, а так же привести ряд ресурсов, с которыми неплохо было бы познакомиться при желании продолжить развитие в проектировании на основе предметной области (DDD: Domain Driven Design).

2. Так почему же DDD?

Есть несколько шаблонов реализации предметной области (Domain Logic) или бизнес-логики (Business Logic):

1) Table Module – представляет собой объект, в единственном экземпляре, обрабатывающий бизнес логику для всех записей в таблице базы данных, либо представления.

2) Transaction Script – организует взаимодействие с бизнес-логикой посредствам процедур, принимающих запросы с уровня представления.

3) Domain Model – непосредственно, объектная модель предметной области, включающая в себя как поведение, так и данные.

Эти шаблоны описаны более подробно Мартином Фаулером, в его книге “Архитектура корпоративных программных приложений. Шаблоны корпоративных приложений(Patterns of Enterprise Application Architecture (P of EAA)). В данной книге он показывает, что первые два шаблона более привлекательны в начале работы с предметной областью, однако так же обращает внимание, что при наращивании сложности логики предметной области стоит больше внимания уделять сопровождению инфраструктуры, используя первые два подхода, это время можно уменьшить, если обратиться в своём решении к третьему из вышеперечисленных шаблонов, так называемой “Модели предметной области”.

На основе этого сделаем небольшой вывод о том, что данный шаблон (“Модель предметной области”) лучше всего подойдёт, к примеру, для такой непростой области, как финансовый рынок. Большинство, создаваемого в наши дни программного обеспечения предназначено для различных нужд бизнеса, следовательно какие-то абстрактные, обобщенные решения находят своё место на рынке (с довольно таки высокой конкуренцией) всё реже и реже. К чему я пишу про всё это? Потому что DDD – это не только качественное проектирование, но так же и показательный пример того, как следует выделить предметную область в программном обеспечении, для того, чтобы проще преодолевать сложности, частые изменения, проблемы коммуникации и прочие недуги предметной области, вместо того чтобы разрабатывать уродливую, сложную для понимания систему, в которой любое изменение или исправление способно обрушить на вас лавину всё новых и новых дефектов.

DDD ни в коем случае не отрицает наследия практик разработки, таких как:

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

3. С чего можно начать?

Если мой “нудный PR”  проектирования на основе предметной области (DDD) вас до сих пор не утомил, то думаю нам стоит продолжить, если же иначе, то посмотрите хотя бы ссылки на материалы.

Первой книгой пролившей свет на DDD для широкой публики была так называемая “Большая синяя книга” (мем. BBB: Big Blue Book): Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans (на русский язык пока не переведена).

Книга довольна подробно рассказывает о том, что из себя представляет DDD, и все связанные аспекты, такие как: язык предметной области, шаблоны, практики проектирования, рефакторинг, моделирование, как сделать разработку гибкой и многое другое. Но даже если вы ознакомитесь со всеми вопросами, поднятыми в книге (что является не совсем простым занятием), вы обратите внимание, что вопросы рассматриваются только с теоретической точки зрения, оставляя весь простор для практики (книга не привязана к конкретной платформе разработки). Для большинства из нас чтение чистой теории, без подкрепления практическими примерами не нравится, в связи с этим можно обратить своё внимание на сокращенную (и свободную для доступа) версию этой книги, подготовленную порталом InfoQ: Domain Driven Design Quickly.

Есть так же несколько хороших презентаций Эрика Ивенса (Eric Evans), с которых можно начать:

1) DDD: putting the model to work

2) Eric Evans on DDD: Strategic Design

На портале InfoQ можно найти множество других презентаций, статей и интервью, посвященных DDD.

Итак, с теоретической частью мы разобрались, где же можно найти примеры практического применения DDD? Отличной книгой для этого является .NET Domain-Driven Design with C#, Problem – Design – Solution написанная Tim McCarthy. 

В этой книге вы наёдете практические примеры:

1) Как проходит процесс проектирования и разработки, от определения требований, до написания кода

2) Как организовывать архитектурные слои в своих решениях

3) Как применять шаблоны и практики DDD

4) Как построить небольшой каркас для DDD

5) Как изолировать домен предметной области от модели

6) Современные паттерны представления данных и взаимодействия с ними (Model-View-ViewModel) в такой среде как WPF (так же применимы к Silverlight) в практики.

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

Вся концепция книги построена на 3 книгах-столпах DDD:

  1. PoEAA Мартина Фаулера
  2. DDD Эрика Ивенса
  3. Applying Domain — Driven Design and Patterns by Jimmy Nilsson’s (“Применение шаблонов проектирования: проблемно-ориентированное проектирование приложений с примерами на C# и .NET” Джимми Нильссона )

В этой книге поверхностно рассмотрены все вопросы, техники и паттерны, применяемые в DDD, все примеры сопровождаются кодом, что упрощает понимание. Книга превосходная, однако русский перевод подкачал, поэтому, рекомендую прочитать оригинал.

 

 

Однако DDD – это не просто практические решения или шаблоны, это мышление и подход, и есть великое множество нюансов, которые необходимо учитывать, если вы решили следовать DDD, таких как: фокусирование на высокий приоритет отдается модели, выработка языка предметной области, контекст модели, процесс моделирования, разделение знаний, рефакторинг, стратегический дизайн и т.д…это является  основной причиной ознакомиться с книгой Эрика Ивенса, так как она даст вам более объемное и глубокое понимание философии DDD.

DDD не привязанны к конкретной технологии, однако соблюдать DDD будет не так просто, без наличия хороших средств и практик в вашем арсенале, таких как: TDD-фреймворк, ORM, возможность реализации независимости сохраняемости (Persistence Ignorance), IoC-контейнер (Inversion of Control), и возможностей AOP (Аспектно-Ориентированного Программирования), конечно не значит, что все эти инструменты нам понадобятся, однако они приблизят нас к реализации DDD на практике. Практичная ценность этих средств в том, что они позволять изолировать модель предметной области, что является ключевой целью DDD. Книга Джимми Нильссона может познакомить вас с возможностями и видами данных инструментов. Джимми так же показывает как использовать шаблоны реализации корпоративных приложений, и строить, благодаря им, цельное решение, основанное на современных инструментах и практиках.

Некоторые реализации шаблонов DDD на Ruby On Rails:

Some DDD (Domain Driven Design) Concepts implemented in Rails

4. Актуальные вопросы DDD

C DDD так же тесно связана такая тема, как DDDD: Distributed Domain Driven Design (Распределенный DDD). DDDD – это DDD в распределенных сценариях. В настоящее время существует не так много ресурсов, посвященных DDDD, в нескольких словах о DDDD: покрывает проблему реализации сообщений и DDD, разделение команд и запросов (Command Query Separation (CQS)) помогает реализовать данный подход. Грег Янг (Greg Young) сообщил, что готовит книгу, посвященную DDDD.

SOA и DDD – это ещё одна объемная тема, часто обсуждаемая Udi Dahan

5. DDD шаблоны, концепции и понятия

В промышленных приложениях DDD использует ряд шаблонов, часть которых описана в книге Эрика Ивенса, но, это не отменяет применение объектно-ориентированного подхода, включающего GoF-шаблонышаблоны Мартина Фаулера, описанные в его PoEAA, Шаблоны интеграции корпоративных приложений и т.д.…

Вот некоторые из них:

6. Примеры приложений

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

Вот они:

1) Приложение Тима Маккарти его проект, описанный в деталях в его книге. Он описывает не только применение шаблонов, но так же акцентирует внимание в разработке модели предметной области с точки зрения DDD.

Проект так же интересен тем, что построен на .NET 3.5 и демонстрирует всю силу современного подхода связывания данных с моделью предметной области (data binding, реализация шаблона MVVM). Так же его стиль примечателен умением выделять абстракции и повторно используемый код.      

2) Следующий проект, на который следует обратить внимание – это приложение разработанное Yves Goeleven, создание данного приложения описано в его блоге (так же посвященному основным концептам DDD). Другим его приложением является DDD-каркас. Следует обратить внимание на его реализацию взаимодействия шаблонов Repository и Specification

3) Billy McCafferty разрабатывает потрясающий open source фреймворк, сфокусированный на DDD, под названием S#arp Architecture. У него есть очень хорошее описание, включающее в себя описание шаблонов и подходов, заключенных в фреймворке. Фреймворк нацелен на разработку ASP.NET MVC приложений с применением NHibernate.

4) C# Domain-Driven Design sample application ( ndddsample ), это приложение, разрабатываемое Джимми Нильссоном, демонстрирует разбиение приложения на ключевые слои с точки зрения DDD. Так же демонстрируется практическое применение шаблонов building block в предметной области перевозки грузов, описанной в его книге.

Этот проект основан на совместной работе компании Эрика Ивенса “Domain Language” и шведской консалтинговой компании “Citerus”.

Цель этого проекта:

  • Показать практическое применение использования DDD с применением .NET.
  • Использование актуальных утилит, технологий и методологий разработки в области .NET, обсуждаемых ALT.NET-коммунити.
  • Привести практические примеры реализации типовых DDD приложений.
  • Показать способ реализации DDD на конкретной платформе, что позволит без труда осуществить тоже самое на любой другой платформе.
  • Помочь в выборе реализуемых практик. Различные подходы позволят сообществу обсудить их и выбрать соответствующий для конкретной реализации.

здесь более подробная информация.

7. Ресурсы по Domain Driven Design

Официальный сайт — http://domaindrivendesign.org/

Группа обсуждений — http://tech.groups.yahoo.com/group/domaindrivendesign/ это взрослая группа, очень хороший источник идей, место для обсуждений всех видов проблем в области DDD. В ней на ваши вопросы могут ответить опытные в DDD люди, даже Эрик Ивенс :-).

Блог Jimmy Bogard’а — http://www.lostechies.com/blogs/jimmy_bogard/default.aspx

Блог Colin Jack’а — http://colinjack.blogspot.com/

Блог Greg Young’а — http://codebetter.com/blogs/gregyoung/default.aspx

Блог Casey Charlton’а — http://devlicio.us/blogs/casey/

Блог Udi Dahan’а — http://www.udidahan.com/

Введение в Domain-Driven Design — http://msdn.microsoft.com/ru-ru/magazine/dd419654.aspx

8. Заключение

Если вы заинтересованы в расширении ваших “объектно-ориентированных горизонтов” в сложных корпоративных системах и изучении новых способов разработки и проектирования, то DDD – именно то что нужно.

http://weblogs.asp.net/arturtrosin/archive/2009/02/09/domain-driven-design-learning.aspx


Делаем блог на ASP.NET MVC, следуя принципам DDD, TDD

Товарищ Vinay ведёт отличный блог, посвещённый тематике разработке на основе предметной области. Сегодня он начал серию постов, в которых собирается рассмотреть пример разработки блога на ASP.NET MVC.

solution_thumb[1] Для того, чтобы следовать его урокам вам понадобятся следующие инструменты:

ASP.NET MVC – здесь всё понятно.

NHibernate и FluentNHibernate – наш объектно-реляционный преобразователь.

StructureMap – для реализации Dependency Injection.

xUnit.Net – для TDD.

MoQ – делаем МОКи.


Chunk Cloud Computing by Jimmy Nilsson

Джимми Нильсон подытожил в своём блоге новый подход к архитектуре приложений, интерес к которому значительно вырос в последнее время: http://jimmynilsson.com/blog/posts/CCC.pdf


Третья встреча Петербургской группы ALT.NET

Третья встреча Петербургской группы ALT.NET, посвященная разработке под ASP.NET MVC, пройдет в четверг, 2го Апреля в 19:00.
Встречи группы проходят по адресу Биржевая Линия дом 14, офис 409 (4й этаж) (карта).

Программа

  • 19:00 – 21:00 — ASP.NET MVC, Александр Попов (c 2006 года Microsoft MVP)

ASP.NET MVC

  1. Краткое Введение в ASP.NET MVC
  2. DDD в ASP.NET MVC
  3. SharpArchitecture
  4. Spark
  5. Patterns

Регистрация на сайте. Ждем вас!