Публичный аккаунт WeChat:Программист Сяо И
«Эта статья участвовала в мероприятии Haowen Convocation Order, щелкните, чтобы просмотреть:Двойные заявки на внутреннюю и внешнюю стороны, призовой фонд в 20 000 юаней ждет вас, чтобы бросить вызов!"
предисловие
При проектировании сложных систем чаще всего используется многоуровневый метод, а самым простым многоуровневым является знакомая трехуровневая концепция mvc.
Для большинства интернет-компаний он обычно делится на пять уровней:基础设施层
,领域服务层
,应用服务层
,网关层
,用户表示层
Не волнуйтесь, говорите медленно, традиционная трехуровневая модель включает в себя уровень управления, сервисный уровень и уровень хранения данных; однако, поскольку архитектура микросервисов была широко распространена в Интернете, предыдущая многоуровневая модель больше не может работать. нести наш существующий бизнес. Давайте сначала поговорим о конкретном понимании этих пяти уровней.
基础设施层
Представляя ресурсы, хранилище и базовые возможности, он не имеет представления о бизнесе.
领域服务层
и应用服务层
В дизайне микросервисов его можно разделить,领域服务层
может следоватьDDD领域设计
провести领域划分
, выполненный в виде модуля домена微服务
, между каждым микросервисомочень сплоченный, они сосредоточены только на своем бизнесе и общаются друг с другом через интерфейсные вызовы. Что касается уровня службы домена и уровня службы приложений, разница между ними заключается в том, чтоУровень службы предметной области является мостом между уровнем службы приложений и уровнем данных.Слой службы приложений уделяет больше внимания модели предметной области, а уровень службы предметной области уделяет больше внимания модели данных..
网关层
и用户表示层
Это легче понять, даВыполнять интерфейсную адаптацию и наслоение данных рендеринга и агрегации., между ними в основном нет основной бизнес-логики, которая в основном отвечает за проверку доступа к интерфейсу и преобразование модели параметров.
Эта многоуровневая схема проектирования может значительно упростить сложные большие системы, и преимущества будут становиться все более заметными в последующих итерациях обслуживания, но как делить и разделять? , какой код поместить в какой слой? , каждый слой и на что следует обратить внимание? Это будет проблема, над которой нашим разработчикам нужно будет подумать и изучить.
Не волнуйтесь! нижеСуть и изобретательность этих пяти слоев будут подробно рассмотрены..(Моя рабочая жизнь не очень длинная, если я чего-то не понимаю, пожалуйста, оставьте сообщение, чтобы указать на большого парня Хайхана)
многослойный дизайн
Нет необходимой связи между многоуровневым дизайном и DDD.В начале проекта доступ к БД тоже был под бизнес-пакетом системы.Позже, когда я связался с дизайном разделения, я понял, что расширять его непросто, который является текущим четырехслойным многослойным дизайном, более разумным. Конечно, это основано на логическом расслоении более сложной системы, здесь не подчеркивается, что каждый слой — это отдельный модуль внутри системы, они могут быть независимыми микросервисами один за другим.Модуль для каждого домена — это один или несколько микросервисов..
Уровень шлюза будет введен в систему веб-приложений для подключенияуровень пользовательского представленияиУровень службы приложений,правильноУровень службы приложенийвнешняя упаковка, ноУровень шлюзаВ этом нет необходимости, вы также можете напрямую открыть уровень службы приложений для подключения к уровню пользовательского представления, вам нужно только пройти некоторую проверку, авторизацию и уровень унифицированного доступа.
Уровень службы приложенийнесет ответственность за ваше выражениеМодель концепции предметной областиЧтобы решить проблему, как правило, необходимо на ранней стадии разобраться, для решения какой проблемы является создание этой службы, какие бизнес-модели предметной области участвуют в этом вопросе, и этот слой должен быть максимально простым, без включения каких-либо бизнес-правил.Просто запланировать объекты домена на следующем уровне для выполнения задачи.
Слой службы приложений представляет собой определение функции, ориентированное на пользователя.Достаточно преобразовать инструкции пользователя в модель ввода, требуемую уровнем предметной области, в то время как бизнес-правила, бизнес-детали, реализация и другие сложные процессы должны быть реализованы на уровне предметной области. ..
Уровень службы доменаОн отвечает за выражение бизнес-правил и бизнес-статуса.Этот уровень должен иметь возможность четко воспринимать поток данных бизнеса и направление ключевых основных процессов, хотя конкретные инструкции по эксплуатации отправляются наУровень хранения(инфраструктурный уровень) для завершения,Слой доменаЭто ядро программного обеспечения для бизнеса.
уровень инфраструктурыОн отвечает за предоставление общих технических возможностей для верхних уровней без четкого восприятия бизнеса верхнего уровня, обеспечение механизма сохранения для уровня доменных служб и передачу сообщений для прикладного уровня. В программных системах это обычно включает службы сохранения данных и различные службы промежуточного программного обеспечения (MySQL
,Redis
,Memcached
,ELK
Ждать).
Каждый слой выполняет свои обязанности, но в основном должны соблюдаться следующие принципы
- Дизайн каждого слоя должен быть сохраненстрого сплоченный, межуровневой зависимости нет, она может зависеть только от своего следующего уровня.
- Если нижнему уровню необходимо связаться с верхним уровнем, он не может пройти
Interface
способ общения, только через промежуточные компоненты (MQ
,CallBackListener
др. техника) осуществить. - Взаимодействие между каждым уровнем должно обеспечивать слабую связь, то есть верхний уровень должен зависеть только от нижнего уровня.
api
пакет, во многих фреймворках RPC и вSpringCloud
,Serviceless
В архитектуре это не так, они будут более свободными, минимизируя связанность системы.
Как разделить поле
На самом деле в этой теме нет однозначного ответа, правил. Один и тот же бизнес может быть разным в разных сценариях. Но проектирование в этом направлении определенно сделает вашу систему более отказоустойчивой. Я резюмирую некоторые из моих личных мыслей для больших парней, чтобы посмотреть
Во-первых, я думаюДизайн домена должен иметь четкие границы, Somatosensory получает запрос, вы сможете быстро узнать, какие услуги я изменю для этого запроса, и какой код изменить для каждой услуги. Служба домена фактически соответствует набору функций. Эти наборы имеют определенные общие черты, такие как одинаковые实体(Entity),值对象(Value Object
. Например, продукты и услуги, такие как создание продуктов, изменение продуктов, размещение продуктов на полках и запрос списков продуктов, принадлежатНабор функций для товарного домена.
Разделение домена — это не одномоментный процесс, потому что вы не можете предсказать направление развития бизнеса через несколько лет, вы должны разделить тонкость домена в соответствии с реальной ситуацией, если вы начнете очень подробный план, вы умрете с треском. Это должны быть сначала крупнозернистые деления, а затем, при необходимости, множественные мелкозернистые деления из определенного крупнозернистого, напримерТоварный центрIC(item center)
В начале товары и услуги делятся.По мере того, как товарный бизнес становится все более и более сложным, может возникнуть необходимость разделить товары и услуги.Категория обслуживания,Служба инвентаризации,Цена услугиЖдать
Службы доменного уровня должны быть независимы от вызывающей стороны.. Поскольку хорошая доменная служба должна заботиться только о вводе и выводе, предоставляемая служба возможностей должна быть общей и ориентирована на разработку предметной области, а не на разработку функций. Напримерполе заказаИмеется интерфейс обслуживания заказов, выполненный в видеcreateOrderForIC
,даватьТоварный центрIC(item center)
Звоните, если есть другие домены, на которых нужно создавать топ-заказы, например сторонние каналы и т.д., то данный интерфейс сервиса будет недоступен и должен быть оформлен какcreateOrder
.
Чтобы узнать больше о моделировании предметной области, пожалуйста, продолжайте обращать вниманиеКолонка практики моделирования предметной области.
Наконец
- Все статьи оригинальные, оригинальность непростая, спасибо платформе Nuggets, я чувствую, что выиграл, помогите Sanlian, пополните
- Все коды, диаграммы последовательности и диаграммы архитектуры, задействованные в статье, являются общими и могут быть получены, оставив сообщение на официальном аккаунте.
- Если в статье есть ошибки, пожалуйста, прокомментируйте и оставьте сообщение, чтобы указать, и добро пожаловать на перепечатку, пожалуйста, отметьте источник