Pull to refresh

Comments 80

Service — отвечает за всю бизнес логику приложения.

Entities — отвечают за работу с базой данных и представляют из себя структуру повторяющую таблицу или документ в базе данных.

Подход с анемичными моделями, конечно, имеет право на существование. Но называть это "чистой архитектурой" — перебор.

Анемичные модели считаются антипатерном.

Я в сервисы обычно выношу логику включающую использование внешних зависимостей (инфраструктурных), которые в коде фигурируют в виде интерфейсов, просто чтобы агрегаты имели логику, которая относится только к ним.
В статье по ссылке нету однозначного утверждения что это плохо. К тому же я не фанат smalltalk. Моя логика в приложении исходит из соображений минимизации связанности в коде. Поэтому если бизнес правила можно поместить в 1 модель, то они помещаются в модель. Если же для решения бизнес задач необходима координация из нескольких моделей, то я размещаю ее в сервисе.

Координация — смотря а каком смысле.


Если это связанные модели в одном контексте (например, пользователь в контексте фотоальбома и его фотографии), то все должно делаться через Aggregate Root.
Если это разные контексты (например, наличие фото в фотоальбоме позволяет использовать сервис знакомств), или разные слои (после добавления фото отправляется емейл) — события.
Если нужно построить PDF с отчётом, сколько пользователей, добавивших фото, воспользовались сервисом знакомств, это уже вполне себе сервис.

В статье по ссылке нету однозначного утверждения что это плохо.

Простите, а вам надо, чтобы авторитетный дядька сказал "НаркотикиАнемичные модели — это плохо, мммкей"? Аргументы против приводят и Фаулер, и Эванс, и все подряд, а уж конечный вывод — дело читателя.


Основная же ошибка — это привязывать модель к таблице в базе данных. Из этого непонятно когда случившегося перехода от "модели сущности" к "модели таблицы в РСУБД" все проблемы. Если мыслить сущностями, сразу очевидно нарушение инкапсуляции.

Проголосовал за "другое...' Рассказываю: воодушевлен CA, но без фанатизма. Приложение готово в любой момент к переходу к CA, но, например, entity жёстко связаны с MobX и поробрасываются во вью (React) как есть, без DTO.

Этот подход на самом деле самый популярный на mobx. Я бы назвал его ленивый CA =)
не в обиду будет сказано, но стоит ли призрачная возможность переезда на другую библиотеку/фреймворк такого количества лишних сущностей?
Я ее использую не столько что бы абстрагироваться от фреймворка сколько абстрагироваться от платформы. Поскольку я пишу не только веб, но и бек, и мобилки, и настольные приложения на C#. И такой подход позволяет мне свободно переключаться между платформами и гибко реагировать на любые повороты в бизнес требованиях.
В книжке Р. Мартина вы пропустили главу Screaming Architecture. Там он прямо говорит, что все вариации MVC не стоит использовать. В связи с этим вся статья становится сомнительной.
Ну и «независимость от UI» для веб-приложения выглядит странно.
Да и независимость от фреймворка для JS — утопия.
Возможно вы ошиблись главой, но не могу найти такого в книге. Книгу я читал очень давно, но на сколько я помню слой представления в ней вообще не рассматривается.
Не, не ошибся. Именно так и называлась. Смысл в том, что части системы должны явно говорить об их назначении и в этом ключе разделение на модели и контроллеры Мартин считает неверным подходом.
И вообще: чистая архитектура всё таки подаётся в привязке к серверной части системы, реализованной на ООП-языке.
Натянуть, к примеру, Go-приложение на эту концепцию ещё можно. Но вот пытаться разрабатывать веб-приложение по принципам чистой архитектуры, на мой взгляд, полнейшая глупость.
Если вы скинете ссылку на его текст, то ситуация проясниться. Пока что совсем не понятно о чем вы говорите.
По поводу веба к счастью разработчики VS Code не посчитали это глупостью и написали на CA приложение на электроне которое не тормозит. Кроме того такой подход из коробки идет у Android и iOs, в iOs даже название Controller сохранено.
По поводу веба к счастью разработчики VS Code не посчитали это глупостью и написали на CA приложение

У меня есть странный вопрос: а где найти подтверждение тому, что разработчики VS Code писали на "Clean Architecture"?


Аналогично:


Чистая архитектура не привязана к какому то конкретному фреймворку, платформе или языку программирования. Десятилетия ее используют для написания настольных приложений. Его эталонную реализацию можно найти во фреймворках для серверных приложений Asp.Net Core

Что такое "эталонная реализация чистой архитектуры в asp.net core"?

Открыть ссылку выше которая приведет прямо на исходники.

Я поискал и не нашел в этих исходниках ни одного упоминания "Clean Architecture".

Clean Architecture в коде никогда не упоминается. Суть чистой архитектуры в организации кода по слоям View, Controller, Service, Repository, Model, ViewModel. Все они у вас перед глазами сразу по ссылке.
Суть чистой архитектуры в организации кода по слоям View, Controller, Service, Repository, Model, ViewModel

Ненене, подождите. Давайте не путать. Когда какая-то команда что-то написала "на Clean Architecture" — это значит, что они взяли книгу и следовали ее правилам. Если же вы просто видите в коде разделение на какие-то области, которые вам кажутся похожими на приведенные в "Clean Architecture" — это значит только то, что вы их там видите. Слоистая архитектура, если что, была задолго до книги Мартина.

Да, Мартин не является автором такого подхода, так же как и Рихтер не является автором CLR. Но Мартин написал популярную книгу рассказывающую о таком подходе и дал название такому подходу, которое стало общепринятым. И Чистая Архитектура дополняет слоистую архитектуру.
Но Мартин написал популярную книгу рассказывающую о таком подходе и дал название такому подходу, которое стало общепринятым.

Неа, не стало. С чего вы это взяли?


Собственно, вообще, "чистая архитектура" — это всего лишь общеупотребительное словосочетание, говорить, что оно соответствует ровно одной архитектуре — это та еще заносчивость.

Согласен что эталонной нет. В том же Asp.Net Core и JavaSpring между ними есть разница. Но тут главное не дословное следование книжке, а сама суть процесса по разделению кода.
а сама суть процесса по разделению кода.

Знаете, любая архитектура — это процесс по разделению кода. Почему вы считаете, что VS Code — это доказательство успешности именно Clean Architecture, а не любой другой?

Хорошо, допустим в VS Code это не ЧА. Тогда давайте найдем что же это за архитектура там применяется.

VSCode архитектура там применяется :) Clean Architecture для меня это принципы по которым можно спроектировать архитектуру и/или по соблюдению которых можно отнести уже существующую к чистой или нечистой. На первый взгляд код VSCode к чистой отнести нельзя.

Хорошо. Если не нравится сравнение с ЧА, давайте по другому. Каким общепринятым названием называется архитектура в которой логика делиться на слои view, controller, model, service, viewModel, repository, entity и так далее...?

Подход который использует VSCode я уже десять лет наблюдаю в ASP.Net. Так что вариант «своя архитектура» не учитывается.
Каким общепринятым названием называется архитектура в которой логика делиться на слои

Layered architecture. PoEAA, первая часть, первая глава. Страница 17 в издании Addison-Wesley 2010 года.

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

Более того. Открываем книгу, глава 21, "SCREAMING ARCHITECTURE" (дадада, вам ее уже поминали"):


So what does the architecture of your application scream? When you look at the top-level directory structure, and the source files in the highest-level package, do they scream “Health Care System,” or “Accounting System,” or “Inventory Management System”? Or do they scream “Rails,” or “Spring/Hibernate,” or “ASP”?
[...]
Just as the plans for a house or a library scream about the use cases of those buildings, so should the architecture of a software application scream about the use cases of the application.

Открываем репозиторий по ссылке: команды, контроллеры, ядро, модели, режимы, сервисы, представления.


Явно противоречит написанному в книге.

Это скорее касается организации кода, нежели архитектуры. У Мартина есть свое мнение, у меня свое. Я стараюсь придерживаться организации кода как по ссылке. У такого подхода тоже свои глубокие корни.
Это скорее касается организации кода, нежели архитектуры

А архитектура — она разве не про организацию кода (в широком смысле)?


У Мартина есть свое мнение, у меня свое. Я стараюсь придерживаться организации кода как по ссылке.

Гм. А я стараюсь придерживаться своего собственного подхода. А что, у Мартина есть свое мнение, у вас свое, у меня — свое. Но у меня все равно "Чистая архитектура" по книжке. Да?

Про организацию в том числе. Но SCREAMING ARCHITECTURE нужно рассматривать отдельно от Clean Architecture. И я считаю ее личным мнением автора книги.

И самый главный момент, книга написана по уже имеющийся архитектуре, а не код организовали по книге.
Но SCREAMING ARCHITECTURE нужно рассматривать отдельно от Clean Architecture.

То есть вы из книги выбираете только удобные вам места?


И я считаю ее личным мнением автора книги.

А Clean Architecture — не считаете?


И самый главный момент, книга написана по уже имеющийся архитектуре

Прекрасно. По какой? Где взять тот конкретный пример (или набор) примеров, по которому написана книга?

Суть чистой архитектуры в организации кода по слоям View, Controller, Service, Repository, Model, ViewModel

Это ваше понимание сути CA? Как мне помнится, в CA четыре слоя и ни один из них так не называется. А даже если провести аналогии, то View и ViewModel — это один слой UI или нет?

В упор не вижу разделения на четыре канонических слоя. Да, может быть можно все каталоги верхнего уровня однозначно определить к одному из слоёв CA, но отсутствие явного подтверждения этому означает, по-моему, что в лучшем случае разработчики VSCode не желают афишировать использование CA. А более вероятно, что однозначно отнести просто не получится. Например, в services смешаны сервисы из разных слоёв и хорошо если каждый отдельный можно отнести к конкретному слою, а не, например, в одном классе сочетаются и элементы usecases, и элементы controllers

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

Services по сути антикорапшн лаер который изолирует вас от того кто вызвает код ваших Entity а Repository это антикорапшн лаер который изолирует вас от того откуда вы получаете данные для ваших Entity. По хорошему если у вас чистая архитектура с богатой моделью то вся логика в Entity если делаете с анемичной моделью то вся логика в DomainService. Не надо путать с тем Service который изолирует ваше приложение. Это ApplicationService. DomainService что-то вычисляет и возвращает результат. Он не использует Repository. Просто принимает входные значения и возвращает результат. Например Validator, AmountCalculator да просто обычный
class Calculator
{
 void Add(int rhs, int lhs) => rhs + lhs;
}

Типичный DomainSerivice. Хотя лично я против анемичной модели и против DomainServices. Чуть подробнее можно тут почитать. habr.com/ru/post/493426
Я работаю в команде. И обычному фронту вообще тяжело понять что такое Service и почему нельзя на jquery скрипт написать. Поэтому я стараюсь не усложнять такими подробностями. Ведь в любом случае это Service =)
В синей книге (DDD) Сервис определен как любой класс без состояния. Ну и разделение такое нужно чтобы отделить те классы без состояния которые служат слоем изоляции от тех классов без состояния которые что-то вычисляют.
Ну и главное вообще что я хотел сказать и что комментатор выше до меня говорил. Я вообще люблю фронтэндшиков. Бывшая девушка фронтом занималась с которой спокойно растилась (добра тебе Маша если это читаешь :) да и сам пишу иногда для себя что-то на фронте на том же Angular и Blazor просто мое ИМХО что для фронта это все излишнее усложнение. Не надо это все там. Типичный фронт это провалидировал и отправил на сервер или получил с сервера и показал что пришло. Вот всякие мобильные или андроид приложение (которые тоже фронт) еще более менее этим всем заморачиваются если у них своя логика есть, а в большинстве случаев — наворачивать там такие слои это просто трата времени.
Смотря что и как писать. Если просто провалидировал и отправил на сервер или получил с сервера и показал что пришло, то да, излишне. А если писать Приложение с большой буквы, то очень даже помогает =).
Хм, я в во всяком тырпрайсе большом и кровавом (вообще Java/C# как раз из этой сферы) и тут логика на фронте может привести к очень веселым последствиям (в финансовом плане). Обычно стараемся делать минимум на фронте и максимум на беке.
На самом деле это стереотип. На беке достаточно иметь защищенное АПИ, для любых клиентов и интеграций. А выдает ваш бек html или json на безопасность никак не влияет.
На беке достаточно иметь защищенное АПИ

… внутри которого валидировать всю бизнес-логику, которую вы уже проделали на клиенте.

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


С точки зрения UX во многих случаях лучше было бы максимально проделать подготовительную работу на фронте, а на бэке лишь проверить на допустимость и отдать флаг успешности. То, что называется offline first.

И обычному фронту вообще тяжело понять что такое Service

Объяснять не пробовали?

Объясняю потихоньку, вот статью даже написал. Но я не бесконечный.

Внезапный вопрос: а почему вдруг приложение, целиком и полностью написанное на asp.net — не веб-приложение?

Полусайт-полуприложение. К тому же весьма дорогое по стоимости поддержке серверов. Отдать клиенту статику и отрендерить на клиенте приложение в сотни раз дешевле.
Полусайт-полуприложение.

Почему? Открываем вики:


a web application or web app is a client–server computer program that the client (including the user interface and client-side logic) runs in a web browser

Приложение на asp.net под это определение попадает.

Есть у меня ощущение, что как только ваши View стали работать отлично от идеоматичного React (принимать контроллер первым параметром, вместо props), то вcякий тулинг Реакта с ними не особенно будет работать.


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

Тулинг работает исправно.
Все данные для переиспользования распологаются в сервисе.
Все данные для переиспользования распологаются в сервисе.

А, почитал еще немного и понял. У вас же DI через property injection, а не через constructor. Тогда да, прокидывать вручную ничего не нужно.

Уважаемый автор, искренне не понимаю вашу ненависть в Angular 2+ )
Да, это не чистая CA, но это один из немногих фрэймворков, который диктует свою архитектуру из коробки, а не порождает зоопарки, извините, говнокода.
Вы написали замечательную статью, но на практике ей вдохновятся единицы, а большая часть сообщество React/Vue так и продолжит порождать в каждом новом проекте новую архитектуру. Раздувать одну бибилиотеку кучей других, потому что из коробки функционала не хватает для большинства real-world проектов.
Как пример — из коробки в React нет TS. Половина будет юзать старый добрый JS, половина перейдет на TS. Дальше хуже — Redux, MobX, просто на хуках. Инструментов великое множество, и каждый такой инструмент зачастую приводит к разнице в архитектуре.

Из-за этого зоопарка, переход между проектами на React/Vue разных команд/компаний очень сложен, так как каждый выстраивает архитектуру как хочет / как умеет. Напротив, при переходе между разными проектами на Angular, вы не ощутите большой разницы и вряд ли встретите какие-либо сюрпризы.

По поводу Angular 1.x (AngularJS) вообще стоит забыть как о страшном сне, это была ошибка, но она привела к созданию Angular 2 =)
Поступок с Angular 1, когда фреймворк просто бросили и написали другой, нанес мне психологическую травму. С тех пор я не доверяю никакому Angular =).

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

Я знаю что 60% разработки на реакте это редакс. А так я предложил успешную концепцию которая справляется с любой задачей по гибкости и производительности. И если хотя бы часть сообщества не побоится использовать такой подход, то это уже хороший шаг к наведению порядка на реакте.
Чем хорош React — он настолько минималистичен, что на его базе вы можете построить проект с хорошей архитектурой.
Чем хорош Angular — это уже сделали за вас, за вашего друга и за вот того разраба, вместо собирания своего холиварного конструкта вы берете и работаете.
Чем хорошо не быть разрабом — вместо собирания своего холиварного конструкта вы берете и не работаете разрабом, круто же никаких холиваров, архитектур и прочего «мусора».
Мне кажется скоро статьи про «замечательную» чистую архитектуру которая «создана» для Front-end приложений будут раздражать сильнее, чем очередная статья от «вирусолога» про корону. Какая эта уже по счету за последнее время?

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

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

Да что вы говорите, правда что ли? Спасибо спаситель, что снизошли с небес чтобы поведать нам «правильное» решение для написания больших приложений, а то мы глупенькие совсем и не знаем что и как писать, чем и как пользоваться, выжимать из инструментов все соки на полную катушку для решения наших задач. А ещё мы настолько ущербные, что пользуемся фреймворками, а не пишем «фреймворконезависимый» и «правильный» код, который спасет нас от всего, а ещё этот код очень «легко» поддерживать, одно «удовольствие» вообще что либо имплементить в рамках такой архитектуры.

(вынесу в корень, многобукав)


Но SCREAMING ARCHITECTURE нужно рассматривать отдельно от Clean Architecture. [...] И самый главный момент, книга написана по уже имеющийся архитектуре, а не код организовали по книге.

Хорошо, давайте посмотрим на только Clean Architecture, это глава 22 соответствующей книги.


Пост:


для примера возьму эталонную реализацию этой архитектуры для Asp.Net Core.

Вот упрощенный пример приложения:

Из кода я оставлю только самое (для меня) важное:


public IndexController(IUserProfileService userProfileService)
public UserProfileService(IUserProfileService userProfileService)
//упс, циклическая зависимость
//наверное, вот это имелось в виду?
public UserProfileService(IUserProfileRepository userProfileRepository)
public UserProfileRepository(DBContext dbContext)

Рисуем цепочку зависимостей: контроллер -> сервис -> репозиторий -> БД. Проверяем себя — в статье явно написано то же самое (это, кстати, важно, потому что одно небольшое изменение радикально изменит архитектуру):


В программе слой Controller зависит от слоя Service, а он зависит от слоя Repository.

Поскольку сервис зависит от репозитория, слой репозитория является внутренним по отношению к слою сервисов. Аналогично, слой БД является внутренним по отношению к слою репозитория. Это соответствует главному правилу из Clean Architecture:


Source code dependencies must point only inward...

… точнее, только первой его части. Потому что вот вторая:


...toward higher-level policies.

Но репозиторий и БД — это не higher-level policy, а деталь имплементации. Проверяем себя (выделение мое):


The software in the interface adapters layer is a set of adapters that convert data from the format most convenient for the use cases and entities, to the format most convenient for some external agency such as the database or the web. [...] No code inward of this circle should know anything at all about the database.

Напомню, что согласно диаграмме в той же главе, слой interface adapters — это слой gateways, второй снаружи. Слой сервисов (бизнес-логики) — третий, и он не может зависеть от репозиториев, размещенных во втором, согласно основному правилу. Следовательно, описанное в статье


он [слой Service] зависит от слоя Repository.

противоречит CA, как она описана в главе 22. Ровно то же самое применимо и к зависимости репозиторий-фреймворк БД (второй и первый слои соответственно).


Вывод: приведенная в статье "эталонная реализация этой архитектуры", как ее объясняет автор статьи, не соответствует принципам, приведенным в главе, на которую автор статьи ссылается.


PS Бонус-пойнт:


Достигается такая гибкость за счет разделения приложения на слои Service, Repository, Model.

Вот только нет таких слоев у Мартина. У него есть четыре слоя:


  1. Frameworks & drivers
  2. Interface Adapters
  3. Application Business Rules
  4. Enterprise Business Rules

Из которых два внутренних еще называются Use Cases и Entities.


Слово Model как название слоя в главе 22 не встречается. Слово Repository там не встречается вообще.


Еще про репозитории (хотя это, конечно, глава 34 уже):


The keen-eyed reader will notice that the OrdersRepository from previous diagrams has been renamed to simply be Orders. [...] To put that another way, we talk about “orders” when we’re having a discussion about the domain, not the “orders repository.”
Боюсь если соблюдать всё что вы написали, то это отпугнет вообще всех фронтенд разработчиков. Можно конечно и интерфейс писать на каждый класс и разделение слоев делать более «эталонным» и вообще сделать все «энтерпрайзненько», но это не решит никаких проблем проекта, только раздует техдолг до огромных масштабов.

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

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


разделение слоев делать более «эталонным»

Что значит "более эталонным", вы говорили, что вы уже привели эталонную архитектуру?


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

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


тем более что автор книги не автор этой архитектуры

А кто автор этой архитектуры?


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

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

Тогда может быть напишите свою статью? Как вы представляете себе ЧА в веб-приложении на любой библиотеке? Вдруг ваш подход и вправду окажется лучше. По обрывкам предложений не понятно.
Как вы представляете себе ЧА в веб-приложении на любой библиотеке?

А я не представляю. Я, собственно, считаю, что ваши заявления о том, что Clean Architecture, описанная Мартином, так хорошо применима и дает такие прекрасные результаты, несколько голословными.


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


Вдруг ваш подход и вправду окажется лучше.

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

> Вот только нет таких слоев у Мартина. У него есть четыре слоя

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

Важную часть забыли: "в сторону внутренних кругов и повышения абстракции" ('toward higher-level policies"). Теперь давайте задумаемся, как же расположить слои "Service, Repository, Model" в порядке повышения абстракции?

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


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


P.S. реальная история – мигрировали библиотеку виджетов с Mithril на Preact. Библиотека была написана грамотно, весь mithril-специфичный код был собран в специальный адаптер, все компоненты работали через него. Но в процессе миграции выяснилось, что API Mithril и Preact отличается, и полностью реализовать тот же самый интерфейс адаптера не получится, надо рефакторить адаптер, а значит и все компоненты целиком.

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

Да вы правы. Логика которая относится к модели нужно размещать в методах модели. В примерах кода так и было сделано. В сервисах помимо склеивание, конкретно у меня есть еще логика по обработке не связанных моделей или массива моделей. Например из массива моделей выбрать подходящие под какие либо условия. Или на основание двух разных моделей получить третью. А также случаи логики не связаны с моделями совсем. Если у вас по другому, расскажите пожалуйста как реализовано у вас.

В статье не хотел усложнять сложными формулировками, но наверное надо будет придумать более удачное описания для этих двух слоев.

Давно уже придумано, Application Service vs Domain Service

Спасибо за подсказку. Теперь буду делить сервисы на Application Services, Infrastructure Services, Domain Services. Так же выделил еще одну группу View Services с логикой для вьюхи, не связанную никак с бизнесом, не зашиваемую в компонент, не относится к паттерну helper. Например генерирует css анимации для разных вьюх на основе состояния бизнес логики. Да да, у меня и такое встречается =)
Выделите ещё штук 15 сервисов, будет ещё лучше ведь. И ещё примените заодно десяток другой паттернов и вообще всё по красоте будет. Что мелочиться то.

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


mamento


будем дублировать между сервисами?

Зачем дублировать? Сервисы можно (и нужно) инжектить друг в друга. Так что если что-то реализовано в одном сервисе — всегда можно использовать эту реализацию и в другом.

Не прибит, в статье про это не рассказал, но менять можно. На один вью может приходиться несколько контроллеров, на один контроллер может приходиться несколько вью. Главное что бы интерфейс сохранялся.
UFO just landed and posted this here
Sign up to leave a comment.

Articles