main

Author: pvaviloff

readme.md

@@ -48,7 +48,7 @@
 
 В команде преследуется цель писать как один разработчик. Что это означает? Эмпирическим путем выявлены принципы и рекомендации, которые работают в рамках общей системы и позволяют писать в одном стиле всей команде. За основу взяты: документация Symfony, SOLID и DDD.
 
-##### С Domain Driven Design берем концепт реализации функционала:
+#### С Domain Driven Design берем концепт реализации функционала:
 
 Написанный код должен иметь смысл не только для программистов, но и для бизнеса. Программист и постановщик должны говорить на "одном языке". Все сущности и свойства должны называться так, как их называет постановщик. Если это Возвраты, то это Refund, если это Заказ, то это Order. По возможности составлять глоссарии, и описывать сущности.
 
@@ -59,7 +59,7 @@
 Также придерживаемся принципа "слоеного пирога". Разграничиваем зоны ответственности и связываем каждую зону при помощи dependency injection (DI).
 ![onion](./images/onion.png)
 
-##### Используется из SOLID:
+#### Используется из SOLID:
 
 The Single Responsibility Principle Сервис должен иметь только одну обязанность. Спокойно реализуется в наших условиях. Как при рефакторинге, так и при разработке нового функционала.
 
@@ -70,7 +70,7 @@ The Interface Segregation Principle Лучше иметь много интер
 
 The Liskov Substitution Principle  Замещения - если S является подтипом T, тогда объекты типа T в программе могут быть замещены объектами типа S без каких-либо изменений желательных свойств. Частично выполним, зависит от реализации.
 
-##### Не используется из SOLID:
+#### Не используется из SOLID:
 
 The Open Closed Principle Класс открыт для расширения закрыт для модификации. Самая большая проблема: не факт что кто-то из другой команды следует принципам SOLID. В проетах где работает 10+ человек стожно поддерживать версионность обектов.