После прочтения всей книги, в общем, помимо нескольких классических шаблонов проектирования, о которых часто говорят, ключевым является разделение границ системы, организация зависимостей и разграничение того, что относится к высокоуровневому бизнес-слою, а что внешние слои деталей.
II парадигма программирования
Структурное программирование, объектно-ориентированное программирование, функциональное программирование.
III дизайн шаблонов
7. Принцип единой ответственности SRP: Принцип единой ответственности
У модуля должна быть одна и только одна причина для изменения. Он отражает сплоченность (Cohesion). SRP находится на уровне метода и класса, повышение до уровня компонентов — это Общий принцип замыкания, а повышение до уровня архитектуры — это граница.
8. Принцип «открыто-закрыто» OCP: принцип «открыто-закрыто»
Открыт для расширения, закрыт для модификации. Путем организации зависимостей компонентов в системе бизнес-логику высокого уровня нельзя будет легко изменить, а базовые политики можно настраивать, расширять и заменять.
9. Принцип подстановки Лисков LSP: принцип подстановки Лисков
10. Принцип разделения интерфейсов Интернет-провайдер: Принцип разделения интерфейсов
11. Зависимость инверсионов IP: принцип инверсии зависимости
IV компонентный режим
12. Компоненты
13. Сплоченность компонентов
14. Соединение компонентов
V Архитектура
15. Что такое архитектура?
16. Независимость
Сценарии использования, разработка, развертывание, эксплуатация и обслуживание должны поддерживать независимость, хорошую развязку.
Хорошая архитектура может начинаться с монолитной архитектуры (независимость на уровне исходного кода), а затем медленно трансформироваться в независимо развертываемую единицу (независимость на уровне развертывания) и, наконец, опираться на независимые сервисы или микросервисы.
Схема разделения системы меняется со временем, и хорошие архитекторы предвидят и способствуют этому изменению.
17. Границы: нарисуйте линии
Демаркация границ на самом деле является применением Принципа единой ответственности (SRP, Single Responsibility Principle).SRP указывает нам, как провести границы. Четкая граница позволяет мне отсрочить принятие решений. Например, ядро бизнеса не имеет ничего общего с выбором базы данных, вводом-выводом и графическим интерфейсом.
18. Пограничная анатомия
Ничего не было проанализировано. Границы находятся в форме вызовов метода в монолите, развертываемых компонентах, потоках, процессах и услугах. Типичная система будет иметь границы уровня уровня обслуживания и локальные. В конце концов, это все еще уровень исходного кода для рассмотрения.
19. Политика и уровень
На том же уровне политики, которые изменяются по одной и той же причине, должны быть организованы в один и тот же компонент — SRP. Чем выше уровень основного бизнеса, тем реже происходят изменения вверху и тем чаще изменения внизу. Здесь задействовано много принципов: принцип единой ответственности, принцип открытости-закрытости, принцип общего замыкания, принцип инверсии зависимостей, принцип стабильных зависимостей, принцип стабильных абстракций.
20. Бизнес-логика Бизнес-правила
Если вы хотите организовать приложение в виде бизнес-ядра и плагинов, вы должны выяснить, что является основным бизнесом системы? Бизнес-правила — это основная функция системы и место, где можно заработать или сэкономить деньги.Это должен быть самый независимый и повторно используемый код в системе. Ключевой бизнес + ключевые бизнес-данные образуют объект экземпляра модели. Вариант использования Вариант использования находится на более низком уровне, чем сущность, вариант использования зависит от сущности.
21. Кричащая архитектура
Кричащая архитектура, Организация кода должна быть замечена после того, как вы знаете, на первый взгляд, что система действительно дела. Архитектура на основе случаев, вместо того, чтобы использовать рамки, рамки представляют собой только инструмент, должен поместить окончательное рассмотрение и может заменить. Хорошая архитектура должна быть легко проверить, а не при условии использования структуры, базы данных.
22. Чистая архитектура
Разделите границы и следуйте принципу зависимости, и вы получите чистую архитектуру. Проще сказать, чем сделать.
23. Ведущие и скромные объекты
Принятие принципа скромных объектов на границах архитектуры повышает тестируемость всей системы. Что такое шаблон скромного объекта? Это касается поведения, которое легко проверить, и поведения, которое трудно протестировать по отдельности. Например, GUI сложно протестировать, но после использования HOP его можно разделить на две категории: Presenter и View, Представление здесь — это скромный объект, который трудно протестировать, поэтому поведение Presenter можно полностью протестировать, а затем в View для отображения передаются простые данные, без сложной логики.
24. Частичные границы
Независимо от того, полностью и строго реализованы архитектурные границы или частично, это вопрос, который необходимо учитывать архитекторам. Здесь предлагаются три подхода к достижению частичных границ: однокомпонентное развертывание, одномерные границы и шаблон фасада.
25. Слои и границы
Пример того, как проектировать слои и структуры, иллюстрируется игрой. Ответственность архитектора состоит в том, чтобы заранее обнаружить границы системы в ходе эволюции системы и взвесить, какие из них следует реализовать полностью, какие следует реализовать частично, а какие можно игнорировать.
26.The Main Component
Main прикладной системы можно рассматривать как подключаемый компонент: загрузить конфигурацию, задать начальные условия, собрать внешние ресурсы, а затем передать логику управления на верхний уровень политик.
27. Услуги: большие и малые
(Я этого не понимаю! @#) Хотя служба системы так же полезна, как и ее масштабируемость и расширяемость, служба не является важным архитектурным элементом. Системная архитектура состоит из границ и зависимостей между ними. Услуга может состоять из одного компонента или состоять из нескольких компонентов, разделенных границами.
28. Тестовая граница
Тестируемость как система также должна быть спроектирована, с одной стороны, следует уделить внимание.
29.Clean Embedded Architecture
Разработчики встраиваемых систем также должны изучить идею архитектуры программного обеспечения, многоуровневости и добавления уровней абстракции.
детали VI
30. Базы данных — это детали
Модель данных связана со схемой, но база данных — это инструмент и деталь.
31. Сеть — это детали
The Web is an IO Device.
32. Рамки — это детали
Не вступайте в брак с каркасом, нарисуйте границу.
2019.1.8 22:32 Ханчжоу