qtmg · January 24, 2018 21:23 · Nov 5, 2016 · Nov 5, 2016 · Apr 2, 2015 · Feb 23, 2015
diff --git a/ddd.md b/ddd.md
@@ -1,4 +1,4 @@
-#Как упороться по DDD, модульной структуре и областям ответственности в Laravel. А потом стать счастливым.
+#Как упороться по модульной структуре и областям ответственности в Laravel. А потом стать счастливым.
 
 > [**UPD**] после пары вопросов в личку, решил добавить дисклеймер: Я не считаю, что это единственно верный путь. Я просто говорю вам о том, что существует такой подход.
 
@@ -228,15 +228,15 @@ $user = User::with('articles')->get();
 
 ![](http://dl1.joxi.net/drive/0007/1611/472651/150217/028da69a3f.jpg)
 
-казалось бы все просто - в области ответственности User есть `UserController`, а в нем метод `profile`. Выбираем пользователей вместе с его статьями, новостями, черновиками... ай! Не бей по рукам! Ну хорошо...  Так делать по DDD нельзя. Мы только что вторглись в чужую область ответственности. Вместо этого нужно обозначить в шаблоне:
+казалось бы все просто - в области ответственности User есть `UserController`, а в нем метод `profile`. Выбираем пользователей вместе с его статьями, новостями, черновиками... ай! Не бей по рукам! Ну хорошо...  Так делать нельзя. Мы только что вторглись в чужую область ответственности. Вместо этого нужно обозначить в шаблоне:
 ```tpl
 {!! Widget::position('user-matherials', $user) !!}
 ```
 и в соответствующих сервис-провайдерах зарегистрировать виджеты для этой позиции. Во все виджеты будет передан объект юзера, с него загрузятся необходимые связи и из связей отрисуются вкладки. Теперь даже если удалим область ответственности News или Article, наш сайт продолжит работу, и все с ним будет хорошо. Так что, я повторюсь... все эти вещи нужно чувствовать очень тонко.
 
 Общение между областями ответственности должно происходить посредством событий и их слушателей. Реже - адаптеров.
 
-Конечно же это еще не DDD. Это лишь одно из условий его обеспечивающих - модульность (слабая связанноть). Сам по себе DDD намного больше, и это скорее философия, чем реальный паттерн. Тем не менее, я надеюсь, что хоть немного пролил свет на модульный подход. Удачи!
+Я надеюсь, что хоть немного пролил свет на модульный подход. Удачи!
 
 -----------------------
 

diff --git a/ddd.md b/ddd.md
@@ -17,7 +17,7 @@
 Все мое приложение поделено на области ответственности. Что это такое? Это такие маленькие участки моего приложения, которые даже можно считать самостоятельными приложениями "вещами в себе" относительно друг друга. Например...
 ![](http://dl2.joxi.net/drive/0007/1611/472651/150217/bd467c4d45.jpg)    
 у меня есть область ответственности User. Она включает в себя модели User, Role, контроллеры управления, авторизации и регистраци, обсерверы, репозитории. В общем все как у полноценного приложения.
-А так же, у меня есть область ответственности Menu, она включает в себя непосредственно Меnu и Items (пункты меню). Все сказоное об области User справедливо и для области Menu. Следите за пространствами имен классов, которые я буду приводить ниже в качестве прмеров, чтобы понять, где мы находимся. И так...
+А так же, у меня есть область ответственности Menu, она включает в себя непосредственно Меnu и Items (пункты меню). Все сказанное об области User справедливо и для области Menu. Следите за пространствами имен классов, которые я буду приводить ниже в качестве прмеров, чтобы понять, где мы находимся. И так...
 
 
 ##Widget-system

diff --git a/ddd.md b/ddd.md
@@ -80,7 +80,7 @@ class Provider extends AbstractProvider{
 	}
 ```
 
-Это означает следующее: как только будет вызван виджет `{!! Widget::show('BackendMenu') !!}` класс Widget найдет внутри себя соответствующий класс, создаст его объект и выполнит на нем метод `render()`, результат исполнения этого метода вернется назад и будет выведен в шаблон. Пример класса-виджета:
+Это означает следующее: как только будет вызван виджет `{!! Widget::show('menu') !!}` класс Widget найдет внутри себя соответствующий класс, создаст его объект и выполнит на нем метод `render()`, результат исполнения этого метода вернется назад и будет выведен в шаблон. Пример класса-виджета:
 
 ```php
 <?php namespace App\Menu\Widgets;

diff --git a/ddd.md b/ddd.md
@@ -74,13 +74,13 @@ class Provider extends AbstractProvider{
 	{
 		#..
 
-		Widget::register('App\Menu\Widgets\SimpleMenuWidget', 'BackendMenu', 'menu', 1);
+		Widget::register('App\Menu\Widgets\SimpleMenuWidget', 'menu');
 
 		#..
 	}
 ```
 
-Это означает следующее: как только будет вызван виджет `{!! Widget::show('menu') !!}` класс Widget найдет внутри себя соответствующий класс, создаст его объект и выполнит на нем метод `render()`, результат исполнения этого метода вернется назад и будет выведен в шаблон. Пример класса-виджета:
+Это означает следующее: как только будет вызван виджет `{!! Widget::show('BackendMenu') !!}` класс Widget найдет внутри себя соответствующий класс, создаст его объект и выполнит на нем метод `render()`, результат исполнения этого метода вернется назад и будет выведен в шаблон. Пример класса-виджета:
 
 ```php
 <?php namespace App\Menu\Widgets;

diff --git a/ddd.md b/ddd.md
@@ -234,7 +234,7 @@ $user = User::with('articles')->get();
 ```
 и в соответствующих сервис-провайдерах зарегистрировать виджеты для этой позиции. Во все виджеты будет передан объект юзера, с него загрузятся необходимые связи и из связей отрисуются вкладки. Теперь даже если удалим область ответственности News или Article, наш сайт продолжит работу, и все с ним будет хорошо. Так что, я повторюсь... все эти вещи нужно чувствовать очень тонко.
 
-Общение между областями ответственности должны происходить посредством событий и их слушателей. Реже - адаптеров.
+Общение между областями ответственности должно происходить посредством событий и их слушателей. Реже - адаптеров.
 
 Конечно же это еще не DDD. Это лишь одно из условий его обеспечивающих - модульность (слабая связанноть). Сам по себе DDD намного больше, и это скорее философия, чем реальный паттерн. Тем не менее, я надеюсь, что хоть немного пролил свет на модульный подход. Удачи!
 

diff --git a/ddd.md b/ddd.md
@@ -234,6 +234,8 @@ $user = User::with('articles')->get();
 ```
 и в соответствующих сервис-провайдерах зарегистрировать виджеты для этой позиции. Во все виджеты будет передан объект юзера, с него загрузятся необходимые связи и из связей отрисуются вкладки. Теперь даже если удалим область ответственности News или Article, наш сайт продолжит работу, и все с ним будет хорошо. Так что, я повторюсь... все эти вещи нужно чувствовать очень тонко.
 
+Общение между областями ответственности должны происходить посредством событий и их слушателей. Реже - адаптеров.
+
 Конечно же это еще не DDD. Это лишь одно из условий его обеспечивающих - модульность (слабая связанноть). Сам по себе DDD намного больше, и это скорее философия, чем реальный паттерн. Тем не менее, я надеюсь, что хоть немного пролил свет на модульный подход. Удачи!
 
 -----------------------

diff --git a/ddd.md b/ddd.md
@@ -230,9 +230,9 @@ $user = User::with('articles')->get();
 
 казалось бы все просто - в области ответственности User есть `UserController`, а в нем метод `profile`. Выбираем пользователей вместе с его статьями, новостями, черновиками... ай! Не бей по рукам! Ну хорошо...  Так делать по DDD нельзя. Мы только что вторглись в чужую область ответственности. Вместо этого нужно обозначить в шаблоне:
 ```tpl
-{!! Widget::position('user-matherials') !!}
+{!! Widget::position('user-matherials', $user) !!}
 ```
-и в соответствующих сервис-провайдерах зарегистрировать виджеты для этой позиции. Теперь даже если удалим область ответственности News или Articles, наш сайт продолжит работу, и все с ним будет хорошо. Так что, я повторюсь... все эти вещи нужно чувствовать очень тонко.
+и в соответствующих сервис-провайдерах зарегистрировать виджеты для этой позиции. Во все виджеты будет передан объект юзера, с него загрузятся необходимые связи и из связей отрисуются вкладки. Теперь даже если удалим область ответственности News или Article, наш сайт продолжит работу, и все с ним будет хорошо. Так что, я повторюсь... все эти вещи нужно чувствовать очень тонко.
 
 Конечно же это еще не DDD. Это лишь одно из условий его обеспечивающих - модульность (слабая связанноть). Сам по себе DDD намного больше, и это скорее философия, чем реальный паттерн. Тем не менее, я надеюсь, что хоть немного пролил свет на модульный подход. Удачи!
 

diff --git a/ddd.md b/ddd.md
@@ -234,7 +234,7 @@ $user = User::with('articles')->get();
 ```
 и в соответствующих сервис-провайдерах зарегистрировать виджеты для этой позиции. Теперь даже если удалим область ответственности News или Articles, наш сайт продолжит работу, и все с ним будет хорошо. Так что, я повторюсь... все эти вещи нужно чувствовать очень тонко.
 
-Конечно же это еще не DDD. Это лишь одно из условий его обеспечивающих - модульность и слабая связанноть. Сам по себе DDD намного больше, и это скорее философия, чем реальный паттерн. Тем не менее, я надеюсь, что хоть немного пролил свет на модульный подход. Удачи!
+Конечно же это еще не DDD. Это лишь одно из условий его обеспечивающих - модульность (слабая связанноть). Сам по себе DDD намного больше, и это скорее философия, чем реальный паттерн. Тем не менее, я надеюсь, что хоть немного пролил свет на модульный подход. Удачи!
 
 -----------------------
 

diff --git a/ddd.md b/ddd.md
@@ -101,7 +101,7 @@ class SimpleMenuWidget implements Renderable {
 ```
 Опустим детали того как именно отрисовывается менюшка в шаблоне 'menu.template' - это сейчас не важно. Вместо этого давайте представим, что нам нужно отрисовать менюшку с одними и теми же пунктами как в шапке, так и в футере, данные одинаковые, а шаблоны разные.
 
-Немного изменим шаблон класс виджета
+Немного изменим класс виджета
 ```php
 <?php namespace App\Menu\Widgets;
 

diff --git a/ddd.md b/ddd.md
@@ -43,7 +43,7 @@ return view('some');
 @include('right-side-bar')
 
 ```
-Как же мы предоставляем переменные, которые должен получать лэйаут? Часто, это бывает что-то в духе `View::share()`. Парни попродвинутее используют View::creator() или View::composer(), которые привязываются к соответствующим шаблнам.
+Как же мы предоставляем переменные, которые должен получать лэйаут? Часто, это бывает что-то в духе `View::share()`. Парни попродвинутее используют View::creator() или View::composer(), которые привязываются к соответствующим шаблонам.
 В чем недостаток подобного подхода? В том, что вы жестко привязаны к этой структуре, и вам нужно модифицировать все это, когда вам нужно что-то добавить или убрать.
 
 Как же эту проблему решает **Widget-system**? А вот так:

diff --git a/ddd.md b/ddd.md
@@ -1,6 +1,6 @@
 #Как упороться по DDD, модульной структуре и областям ответственности в Laravel. А потом стать счастливым.
 
-> **UPD**: после пары вопросов в личку, решил добавить дисклеймер: Я не считаю, что это единственно верный путь. Я просто говорю вам о том, что существует такой подход.
+> [**UPD**] после пары вопросов в личку, решил добавить дисклеймер: Я не считаю, что это единственно верный путь. Я просто говорю вам о том, что существует такой подход.
 
 Когда меня спрашивают для чего нужны сервис-провайдеры в Laravel, я пожимаю плечами и говорю: если вы не знаете зачем они нужны, значит они вам не нужны. Если вы пишите и строите код так, как это описано во всех мануалах, скорее всего вам хватит одного провайдера на всё приложение, и он уже есть сразу. И не надо парить мозг себе и людям. Просто забейте на это все.
 

diff --git a/ddd.md b/ddd.md
@@ -1,6 +1,6 @@
 #Как упороться по DDD, модульной структуре и областям ответственности в Laravel. А потом стать счастливым.
 
-> **UPD** после пары вопросов в личку, решил добавить дисклеймер: Я не считаю, что это единственно верный путь. Я просто говорю вам о том, что существует такой подход.
+> **UPD**: после пары вопросов в личку, решил добавить дисклеймер: Я не считаю, что это единственно верный путь. Я просто говорю вам о том, что существует такой подход.
 
 Когда меня спрашивают для чего нужны сервис-провайдеры в Laravel, я пожимаю плечами и говорю: если вы не знаете зачем они нужны, значит они вам не нужны. Если вы пишите и строите код так, как это описано во всех мануалах, скорее всего вам хватит одного провайдера на всё приложение, и он уже есть сразу. И не надо парить мозг себе и людям. Просто забейте на это все.
 

diff --git a/ddd.md b/ddd.md
@@ -1,6 +1,6 @@
 #Как упороться по DDD, модульной структуре и областям ответственности в Laravel. А потом стать счастливым.
 
-> **UPD** после пары вопросов в личку, решил добавить дискеймер: Я не считаю, что это единственно верный путь. Я просто говорю вам о том, что существует такой подход.
+> **UPD** после пары вопросов в личку, решил добавить дисклеймер: Я не считаю, что это единственно верный путь. Я просто говорю вам о том, что существует такой подход.
 
 Когда меня спрашивают для чего нужны сервис-провайдеры в Laravel, я пожимаю плечами и говорю: если вы не знаете зачем они нужны, значит они вам не нужны. Если вы пишите и строите код так, как это описано во всех мануалах, скорее всего вам хватит одного провайдера на всё приложение, и он уже есть сразу. И не надо парить мозг себе и людям. Просто забейте на это все.
 

diff --git a/ddd.md b/ddd.md
@@ -2,7 +2,7 @@
 
 > **UPD** после пары вопросов в личку, решил добавить дискеймер: Я не считаю, что это единственно верный путь. Я просто говорю вам о том, что существует такой подход.
 
-Когда меня спрашивают для чего нужны сервис-провайдеры в Laravel, я пожимаю плечами и говорю: если вы не знаете зачем они нужны, значит они вам не нужны. Если вы пишите и строите код так, как это описано во всех мануалах, скорее всего вам хватит одного провайдера на все приложение, и он уже есть сразу. И не надо парить мозг себе и людям. Просто забейте на это все.
+Когда меня спрашивают для чего нужны сервис-провайдеры в Laravel, я пожимаю плечами и говорю: если вы не знаете зачем они нужны, значит они вам не нужны. Если вы пишите и строите код так, как это описано во всех мануалах, скорее всего вам хватит одного провайдера на всё приложение, и он уже есть сразу. И не надо парить мозг себе и людям. Просто забейте на это все.
 
 Дефолтная структура приложения на laravel выглядит вот так: У вас есть папка `Http` в которой лежат посредники(раньше это были фильтры) и контроллеры. Так же есть команды, хэндлеры, исключения, модели (последние Тейлор бессовестно бросил просто так - прямо в корне app )... возможно вы сами создаете папки репозиториев, обсерверов... или что-то там еще... потом вы начинаете строить приложение...
 

diff --git a/ddd.md b/ddd.md
@@ -6,7 +6,7 @@
 
 Дефолтная структура приложения на laravel выглядит вот так: У вас есть папка `Http` в которой лежат посредники(раньше это были фильтры) и контроллеры. Так же есть команды, хэндлеры, исключения, модели (последние Тейлор бессовестно бросил просто так - прямо в корне app )... возможно вы сами создаете папки репозиториев, обсерверов... или что-то там еще... потом вы начинаете строить приложение...
 
-Вот вы усердно строите свой код, прилежно создаете свои классы, аккуратно распихиваете их по папочкам. У вас получается большое приложение которое делает все что нужно, ну прям Code Happy по Daylee Rees. И вот в какой-то момент, вы решаете внедрить новую фичу взамен старой.  И что же происходит? Вы как индейцы скачете по своим вьюхам выпиливая переменные, шерстите модели переназначая связи... и задерживаете дыхание в очередной раз обновляя страницу... ну вот - слава богу вы все выпили и перепили... а через неделю на какой-то далекой странице на которую никто не ходит, вдруг оказалось, что что-то не работает... вы просто забыли что там, еще что-то было... ну да и хрен с ней, все равно эта страница никому не нравилась. Или нет? Все верно - это ваш код. И он не работает. Вы послушно получаете пинка от заказчика/начальника и идёте чинить этот геморрой. Но ведь можно было всего этого избежать...
+Вот вы усердно строчите свой код, прилежно создаете свои классы, аккуратно распихиваете их по папочкам. У вас получается большое приложение которое делает все что нужно, ну прям Code Happy по Daylee Rees. И вот в какой-то момент, вы решаете внедрить новую фичу взамен старой.  И что же происходит? Вы как индейцы скачете по своим вьюхам выпиливая переменные, шерстите модели переназначая связи... и задерживаете дыхание в очередной раз обновляя страницу... ну вот - слава богу вы все выпили и перепили... а через неделю на какой-то далекой странице на которую никто не ходит, вдруг оказалось, что что-то не работает... вы просто забыли что там, еще что-то было... ну да и хрен с ней, все равно эта страница никому не нравилась. Или нет? Все верно - это ваш код. И он не работает. Вы послушно получаете пинка от заказчика/начальника и идёте чинить этот геморрой. Но ведь можно было всего этого избежать...
 
 Давайте я покажу вам вот такую структуру приложения:
 ![](http://dl2.joxi.net/drive/0007/1611/472651/150217/20dfd24777.jpg)

diff --git a/ddd.md b/ddd.md
@@ -83,7 +83,7 @@ class Provider extends AbstractProvider{
 Это означает следующее: как только будет вызван виджет `{!! Widget::show('menu') !!}` класс Widget найдет внутри себя соответствующий класс, создаст его объект и выполнит на нем метод `render()`, результат исполнения этого метода вернется назад и будет выведен в шаблон. Пример класса-виджета:
 
 ```php
-<;?php namespace App\Menu\Widgets;
+<?php namespace App\Menu\Widgets;
 
 use Illuminate\Contracts\Support\Renderable;
 use App\Menu\Models\Item;
@@ -103,7 +103,7 @@ class SimpleMenuWidget implements Renderable {
 
 Немного изменим шаблон класс виджета
 ```php
-<;?php namespace App\Menu\Widgets;
+<?php namespace App\Menu\Widgets;
 
 use Illuminate\Contracts\Support\Renderable;
 use App\Menu\Models\Item;
@@ -136,7 +136,7 @@ class SimpleMenuWidget implements Renderable {
 Но вот же косяк... таким образом мы получили два запроса в базу, а ведь переменные одни и те же... Widget-system знает об этой проблеме. Нужно лишь переделать немного класс виджета.
 
 ```php
-<;?php namespace App\Menu\Widgets;
+<?php namespace App\Menu\Widgets;
 
 use App\Menu\Models\Item;
 

diff --git a/ddd.md b/ddd.md
@@ -234,7 +234,7 @@ $user = User::with('articles')->get();
 ```
 и в соответствующих сервис-провайдерах зарегистрировать виджеты для этой позиции. Теперь даже если удалим область ответственности News или Articles, наш сайт продолжит работу, и все с ним будет хорошо. Так что, я повторюсь... все эти вещи нужно чувствовать очень тонко.
 
-Надеюсь, что я хоть немного пролил свет на модульный подход. Удачи!
+Конечно же это еще не DDD. Это лишь одно из условий его обеспечивающих - модульность и слабая связанноть. Сам по себе DDD намного больше, и это скорее философия, чем реальный паттерн. Тем не менее, я надеюсь, что хоть немного пролил свет на модульный подход. Удачи!
 
 -----------------------
 

diff --git a/ddd.md b/ddd.md
@@ -1,6 +1,6 @@
 #Как упороться по DDD, модульной структуре и областям ответственности в Laravel. А потом стать счастливым.
 
-> **UPD** после пары вопросов в личку, решил добавить дискеймер: Я не считаю, что это единственно верный путь. Я просто говорю о том, что существует такой подход.
+> **UPD** после пары вопросов в личку, решил добавить дискеймер: Я не считаю, что это единственно верный путь. Я просто говорю вам о том, что существует такой подход.
 
 Когда меня спрашивают для чего нужны сервис-провайдеры в Laravel, я пожимаю плечами и говорю: если вы не знаете зачем они нужны, значит они вам не нужны. Если вы пишите и строите код так, как это описано во всех мануалах, скорее всего вам хватит одного провайдера на все приложение, и он уже есть сразу. И не надо парить мозг себе и людям. Просто забейте на это все.
 

diff --git a/ddd.md b/ddd.md
@@ -1,5 +1,7 @@
 #Как упороться по DDD, модульной структуре и областям ответственности в Laravel. А потом стать счастливым.
 
+> **UPD** после пары вопросов в личку, решил добавить дискеймер: Я не считаю, что это единственно верный путь. Я просто говорю о том, что существует такой подход.
+
 Когда меня спрашивают для чего нужны сервис-провайдеры в Laravel, я пожимаю плечами и говорю: если вы не знаете зачем они нужны, значит они вам не нужны. Если вы пишите и строите код так, как это описано во всех мануалах, скорее всего вам хватит одного провайдера на все приложение, и он уже есть сразу. И не надо парить мозг себе и людям. Просто забейте на это все.
 
 Дефолтная структура приложения на laravel выглядит вот так: У вас есть папка `Http` в которой лежат посредники(раньше это были фильтры) и контроллеры. Так же есть команды, хэндлеры, исключения, модели (последние Тейлор бессовестно бросил просто так - прямо в корне app )... возможно вы сами создаете папки репозиториев, обсерверов... или что-то там еще... потом вы начинаете строить приложение...

diff --git a/ddd.md b/ddd.md
@@ -53,7 +53,7 @@ return view('some');
 {!! Widget::position('right-side-bar') !!}
 
 ```
-В не зависимости от того, определены ли виджеты, этот код уже работает, и не будет выдавать ошибок.
+Вне зависимости от того, определены ли виджеты, этот код уже работает, и не будет выдавать ошибок.
 А теперь заглянем в сервис провайдер области ответственности Menu:
 ```php
 
@@ -215,12 +215,12 @@ User::addRelation('articles', function(Model $user){
 })
 ```
 
-И теперь наш класс User  модет использоваться
+И теперь наш класс User  может использоваться так:
 ```
 $user = User::with('articles')->get();
 ```
 
-А теперь обратите внимание, что мы ни разу не вторглись в области ответственности User, но при этом привязали к нему статьи. Мы не вторглись в область ответственности Frontend, которая хранит лэйауты для фронта и отвечает за отображение главной страницы. Тем не менее, главная страница упакована необходимыми меню и модулями.
+А теперь обратите внимание, что мы ни разу не вторглись в область ответственности User, но при этом привязали к нему статьи. Мы не вторглись в область ответственности Frontend, которая хранит лэйауты для фронта и отвечает за отображение главной страницы. Тем не менее, главная страница упакована необходимыми меню и модулями.
 
 Для того, чтобы начать так работать нужно очень чутко ощущать эти самые области ответственности, и очень тонко понимать что и зачем делается, и что к чему относится. Это совсем не просто. Возьмем простой пример, профиль пользователя. И в нем закладки
 

diff --git a/ddd.md b/ddd.md
@@ -14,8 +14,8 @@
 
 Все мое приложение поделено на области ответственности. Что это такое? Это такие маленькие участки моего приложения, которые даже можно считать самостоятельными приложениями "вещами в себе" относительно друг друга. Например...
 ![](http://dl2.joxi.net/drive/0007/1611/472651/150217/bd467c4d45.jpg)    
-у меня есть область ответственности User Она включает в себя модели User, Role, контроллеры управления, авторизации и регистраци, обсерверы, репозитории. В общем все как у полноценного приложения.
-А так же, у меня есть область ответственности Menu, она включает в себя непосредственно Меnu и Items (пункты меню). Все сказоное об области User справедливо и для области Menu. Следите за пространствами имен классов, которые я буду приводить ниже, в качестве прмеров, чтобы понять, где мы находимся. И так...
+у меня есть область ответственности User. Она включает в себя модели User, Role, контроллеры управления, авторизации и регистраци, обсерверы, репозитории. В общем все как у полноценного приложения.
+А так же, у меня есть область ответственности Menu, она включает в себя непосредственно Меnu и Items (пункты меню). Все сказоное об области User справедливо и для области Menu. Следите за пространствами имен классов, которые я буду приводить ниже в качестве прмеров, чтобы понять, где мы находимся. И так...
 
 
 ##Widget-system

diff --git a/ddd.md b/ddd.md
@@ -9,7 +9,7 @@
 Давайте я покажу вам вот такую структуру приложения:
 ![](http://dl2.joxi.net/drive/0007/1611/472651/150217/20dfd24777.jpg)
 Что, если я скажу вам, что я могу удалить любую из этих папок и мое приложение продолжит работать, как ни в чем не бывало? Вы не поверите? И правильно - еще мне нужно будет удалить провайдер из загрузки =)
-Как же это стало возможным? А возможным это стало благодаря двум крохотным пакетам: [**Widget-system**](https://github.com/greabock/widget-system) и [**Tentacle**](https://github.com/greabock/tentacles) (оба пакета работают как на laravel 4, так и на laravel 5). Но обо всем по порядку. Начнем со структуры приложения...
+Как же это стало возможным? А возможным это стало благодаря двум крохотным пакетам: [**Widget-system**](https://github.com/greabock/widget-system) и [**Tentacle**](https://github.com/greabock/tentacles) Оба пакета работают как на laravel 4, так и на laravel 5. Однако все примеры будут приведены для laravel 5. Но обо всем по порядку. Начнем со структуры приложения...
 
 
 Все мое приложение поделено на области ответственности. Что это такое? Это такие маленькие участки моего приложения, которые даже можно считать самостоятельными приложениями "вещами в себе" относительно друг друга. Например...

diff --git a/ddd.md b/ddd.md
@@ -9,7 +9,7 @@
 Давайте я покажу вам вот такую структуру приложения:
 ![](http://dl2.joxi.net/drive/0007/1611/472651/150217/20dfd24777.jpg)
 Что, если я скажу вам, что я могу удалить любую из этих папок и мое приложение продолжит работать, как ни в чем не бывало? Вы не поверите? И правильно - еще мне нужно будет удалить провайдер из загрузки =)
-Как же это стало возможным? А возможным это стало благодаря двум крохотным пакетам: [**Widget-system**](https://github.com/greabock/widget-system) и [**Tentacle**](https://github.com/greabock/tentacles). Но обо всем по порядку. Начнем со структуры приложения...
+Как же это стало возможным? А возможным это стало благодаря двум крохотным пакетам: [**Widget-system**](https://github.com/greabock/widget-system) и [**Tentacle**](https://github.com/greabock/tentacles) (оба пакета работают как на laravel 4, так и на laravel 5). Но обо всем по порядку. Начнем со структуры приложения...
 
 
 Все мое приложение поделено на области ответственности. Что это такое? Это такие маленькие участки моего приложения, которые даже можно считать самостоятельными приложениями "вещами в себе" относительно друг друга. Например...

diff --git a/ddd.md b/ddd.md
@@ -15,7 +15,7 @@
 Все мое приложение поделено на области ответственности. Что это такое? Это такие маленькие участки моего приложения, которые даже можно считать самостоятельными приложениями "вещами в себе" относительно друг друга. Например...
 ![](http://dl2.joxi.net/drive/0007/1611/472651/150217/bd467c4d45.jpg)    
 у меня есть область ответственности User Она включает в себя модели User, Role, контроллеры управления, авторизации и регистраци, обсерверы, репозитории. В общем все как у полноценного приложения.
-А так же, у меня есть область ответственности Menu, она включает в себя непосредственно Меnu и Items (пункты меню). Все сказоное об области User справедливо и для области Menu. Следите за пространствами имен классов, которые я буду приводить ниже, чтобы понять, где мы находимся. И так...
+А так же, у меня есть область ответственности Menu, она включает в себя непосредственно Меnu и Items (пункты меню). Все сказоное об области User справедливо и для области Menu. Следите за пространствами имен классов, которые я буду приводить ниже, в качестве прмеров, чтобы понять, где мы находимся. И так...
 
 
 ##Widget-system

diff --git a/ddd.md b/ddd.md
@@ -15,7 +15,7 @@
 Все мое приложение поделено на области ответственности. Что это такое? Это такие маленькие участки моего приложения, которые даже можно считать самостоятельными приложениями "вещами в себе" относительно друг друга. Например...
 ![](http://dl2.joxi.net/drive/0007/1611/472651/150217/bd467c4d45.jpg)    
 у меня есть область ответственности User Она включает в себя модели User, Role, контроллеры управления, авторизации и регистраци, обсерверы, репозитории. В общем все как у полноценного приложения.
-А так же, у меня есть область ответственности Menu, она включает в себя непосредственно Меnu и Items (пункты меню). Все сказоное об области User справедливо и для области Menu. И так...
+А так же, у меня есть область ответственности Menu, она включает в себя непосредственно Меnu и Items (пункты меню). Все сказоное об области User справедливо и для области Menu. Следите за пространствами имен классов, которые я буду приводить ниже, чтобы понять, где мы находимся. И так...
 
 
 ##Widget-system

diff --git a/ddd.md b/ddd.md
@@ -236,6 +236,6 @@ $user = User::with('articles')->get();
 
 -----------------------
 
-P.S. Если вам вдруг тоже приспичит упороться, пользуйтесь этими пакетами аккуратно, они еще сыроваты и скорее всего будут дорабатываться.
+P.S. Если вам вдруг тоже приспичит упороться, пользуйтесь этими пакетами аккуратно, они еще сыроваты и скорее всего будут дорабатываться. Доки по пакетам пока что убогие) но основные их возможности уже были изложены в данной статье.
 
 P.P.S. Отдельное спасибо [@sleeping-owl](https://github.com/sleeping-owl). Ну и спасибо всему [Cooбществу](https://vk.com/laravel_rus). Пишите в [чатике](https://gitter.im/LaravelRUS/chat#), курите [мануалы](http://laravel.su/docs/)
diff --git a/ddd.md b/ddd.md
@@ -13,7 +13,7 @@
 
 
 Все мое приложение поделено на области ответственности. Что это такое? Это такие маленькие участки моего приложения, которые даже можно считать самостоятельными приложениями "вещами в себе" относительно друг друга. Например...
-![](http://dl2.joxi.net/drive/0007/1611/472651/150217/bd467c4d45.jpg)
+![](http://dl2.joxi.net/drive/0007/1611/472651/150217/bd467c4d45.jpg)    
 у меня есть область ответственности User Она включает в себя модели User, Role, контроллеры управления, авторизации и регистраци, обсерверы, репозитории. В общем все как у полноценного приложения.
 А так же, у меня есть область ответственности Menu, она включает в себя непосредственно Меnu и Items (пункты меню). Все сказоное об области User справедливо и для области Menu. И так...
 

diff --git a/ddd.md b/ddd.md
@@ -12,7 +12,10 @@
 Как же это стало возможным? А возможным это стало благодаря двум крохотным пакетам: [**Widget-system**](https://github.com/greabock/widget-system) и [**Tentacle**](https://github.com/greabock/tentacles). Но обо всем по порядку. Начнем со структуры приложения...
 
 
-Все мое приложение поделено на области ответственности. Что это такое? Это такие маленькие участки моего приложения, которые даже можно считать самостоятельными приложениями "вещами в себе" относительно друг друга. Например... у меня есть область ответственности User Она включает в себя модели User, Role и Их контроллеры. А так же контроллеры авторизации и регистрации. А так же, у меня есть область ответственности Menu, она включает в себя непосредственно Меnu и Items (пункты меню). И так...
+Все мое приложение поделено на области ответственности. Что это такое? Это такие маленькие участки моего приложения, которые даже можно считать самостоятельными приложениями "вещами в себе" относительно друг друга. Например...
+![](http://dl2.joxi.net/drive/0007/1611/472651/150217/bd467c4d45.jpg)
+у меня есть область ответственности User Она включает в себя модели User, Role, контроллеры управления, авторизации и регистраци, обсерверы, репозитории. В общем все как у полноценного приложения.
+А так же, у меня есть область ответственности Menu, она включает в себя непосредственно Меnu и Items (пункты меню). Все сказоное об области User справедливо и для области Menu. И так...
 
 
 ##Widget-system
@@ -53,12 +56,26 @@ return view('some');
 В не зависимости от того, определены ли виджеты, этот код уже работает, и не будет выдавать ошибок.
 А теперь заглянем в сервис провайдер области ответственности Menu:
 ```php
-public function boot()
-{
-  #...
-  Widget::register('App\Menu\Widgets\SimpleMenuWidget', 'menu');
-  #...
-}
+
+<?php namespace App\Menu;
+
+use Widget;
+use App\Core\Providers\AbstractProvider;
+
+#..
+
+class Provider extends AbstractProvider{
+
+  #..
+
+	public function boot()
+	{
+		#..
+
+		Widget::register('App\Menu\Widgets\SimpleMenuWidget', 'BackendMenu', 'menu', 1);
+
+		#..
+	}
 ```
 
 Это означает следующее: как только будет вызван виджет `{!! Widget::show('menu') !!}` класс Widget найдет внутри себя соответствующий класс, создаст его объект и выполнит на нем метод `render()`, результат исполнения этого метода вернется назад и будет выведен в шаблон. Пример класса-виджета:

diff --git a/ddd.md b/ddd.md
@@ -47,7 +47,7 @@ return view('some');
 {!! Widget::show('menu') !!}
 {!! Widget::position('left-side-bar') !!}
 @yield('content')
-{!! Widget::position('left-side-bar') !!}
+{!! Widget::position('right-side-bar') !!}
 
 ```
 В не зависимости от того, определены ли виджеты, этот код уже работает, и не будет выдавать ошибок.