├── .github
    └── workflows
    │   └── hugo.yaml
├── .gitignore
├── .gitmodules
├── .hugo_build.lock
├── README.md
├── archetypes
    └── default.md
├── assets
    └── css
    │   └── extended
    │       ├── backlinks.css
    │       └── dracula.css
├── config.yml
├── configTaxo.yml
├── content
    ├── 2023
    │   ├── 03
    │   │   └── 2023031521421111_sign_check.md
    │   ├── 04
    │   │   ├── 2023042606481565_http_load_balancer.jpg
    │   │   ├── 2023042606481565_http_load_balancer.md
    │   │   └── 2023042919261345_microservice_api_testing_strategy.md
    │   └── 05
    │   │   ├── 20230506160801-1.jpg
    │   │   ├── 20230506160801-one-time-passwords.md
    │   │   ├── 2023052517181717_surrogate_keys.md
    │   │   └── 2023053020281611_online_widget_telegram_bot.md
    ├── archives.md
    └── search.md
├── layouts
    ├── _default
    │   └── single.html
    └── partials
    │   └── backlinks.html
├── linear_cases_list.md
├── static
    └── img
    │   └── case_http_load_balancer.jpg
└── template.md


/.github/workflows/hugo.yaml:
--------------------------------------------------------------------------------
 1 | # Sample workflow for building and deploying a Hugo site to GitHub Pages
 2 | name: Deploy Hugo site to Pages
 3 | 
 4 | on:
 5 |   # Runs on pushes targeting the default branch
 6 |   push:
 7 |     branches:
 8 |       - master
 9 | 
10 |   # Allows you to run this workflow manually from the Actions tab
11 |   workflow_dispatch:
12 | 
13 | # Sets permissions of the GITHUB_TOKEN to allow deployment to GitHub Pages
14 | permissions:
15 |   contents: read
16 |   pages: write
17 |   id-token: write
18 | 
19 | # Allow only one concurrent deployment, skipping runs queued between the run in-progress and latest queued.
20 | # However, do NOT cancel in-progress runs as we want to allow these production deployments to complete.
21 | concurrency:
22 |   group: "pages"
23 |   cancel-in-progress: false
24 | 
25 | # Default to bash
26 | defaults:
27 |   run:
28 |     shell: bash
29 | 
30 | jobs:
31 |   # Build job
32 |   build:
33 |     runs-on: ubuntu-latest
34 |     env:
35 |       HUGO_VERSION: 0.115.4
36 |     steps:
37 |       - name: Install Hugo CLI
38 |         run: |
39 |           wget -O ${{ runner.temp }}/hugo.deb https://github.com/gohugoio/hugo/releases/download/v${HUGO_VERSION}/hugo_extended_${HUGO_VERSION}_linux-amd64.deb \
40 |           && sudo dpkg -i ${{ runner.temp }}/hugo.deb          
41 |       - name: Install Dart Sass
42 |         run: sudo snap install dart-sass
43 |       - name: Checkout
44 |         uses: actions/checkout@v3
45 |         with:
46 |           submodules: recursive
47 |           fetch-depth: 0
48 |       - name: Setup Pages
49 |         id: pages
50 |         uses: actions/configure-pages@v3
51 |       - name: Install Node.js dependencies
52 |         run: "[[ -f package-lock.json || -f npm-shrinkwrap.json ]] && npm ci || true"
53 |       - name: Build with Hugo
54 |         env:
55 |           # For maximum backward compatibility with Hugo modules
56 |           HUGO_ENVIRONMENT: production
57 |           HUGO_ENV: production
58 |         run: |
59 |           hugo \
60 |             --gc \
61 |             --minify \
62 |             --baseURL "${{ steps.pages.outputs.base_url }}/"          
63 |       - name: Upload artifact
64 |         uses: actions/upload-pages-artifact@v1
65 |         with:
66 |           path: ./public
67 | 
68 |   # Deployment job
69 |   deploy:
70 |     environment:
71 |       name: github-pages
72 |       url: ${{ steps.deployment.outputs.page_url }}
73 |     runs-on: ubuntu-latest
74 |     needs: build
75 |     steps:
76 |       - name: Deploy to GitHub Pages
77 |         id: deployment
78 |         uses: actions/deploy-pages@v2


--------------------------------------------------------------------------------
/.gitignore:
--------------------------------------------------------------------------------
1 | public
2 | 


--------------------------------------------------------------------------------
/.gitmodules:
--------------------------------------------------------------------------------
1 | [submodule "themes/PaperMod"]
2 | 	path = themes/PaperMod
3 | 	url = https://github.com/adityatelange/hugo-PaperMod.git
4 | 


--------------------------------------------------------------------------------
/.hugo_build.lock:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/ru-arc/archicases/912350e8fd6fd029bc09c313da275ae680b6851f/.hugo_build.lock


--------------------------------------------------------------------------------
/README.md:
--------------------------------------------------------------------------------
 1 | # Архитектурные этюды
 2 | 
 3 | Телеграм канал проекта: [@archicases](https://t.me/archicases)
 4 | 
 5 | 
 6 | ## Идея
 7 | 
 8 | Часто в разные чаты прилетают запросы на разбор реальных архитектурных кейсов. При этом в больших группах:
 9 | 
10 | - Сложно обсудить кейс, так как у каждого свой интерес и обсуждение постоянно уходит то в одну сторону, то в другую,
11 | - Во время обсуждения сложно определить, что относится к обсуждению кейса, а что – нет, так как параллельно может идти несколько обсуждений разных тем,
12 | - Вследствие вышесказанного бывает сложно найти ответы на свой вопрос, тем более спустя некоторое время.
13 | 
14 | Для решения этих проблем создал отдельную группу: https://t.me/archicases
15 | 
16 | В этой группе:
17 | 
18 | - Публикуются только кейсовые вопросы
19 | - Каждый кейс публикуется в собственном топике
20 | - Обсуждение ведется с минимальными, но все же правилами, призванными структурировать обсуждение и сфокусировать его вокруг кейса
21 | 
22 | Это не первая попытка организовать подобную деятельность. Первая была в 2020-м, но тогда основной замысел был в очных встречах и случился локдаун. 
23 | 
24 | ## Процесс работы
25 | 
26 | Основной критерий для публикации кейса: не выдуманная ситуация, так как к выдуманной ситуации можно постоянно придумывать все новые обстоятельства, что заведет обсуждение в «бесконечный тупик».
27 | 
28 | Уровень вопросов абсолютно любой, - EA/Solution/System.
29 | 
30 | Чтобы организовать обсуждение:
31 | 
32 | 1. Написать в личку Сергею Баранову ([@sergey486](https://t.me/sergey486)) о том, что хотите разобрать кейс
33 | 2. Прислать ([пример](https://t.me/archicases/56/58))
34 |     1. Тема (название топика)
35 |     2. Вопрос, на который ищите ответ («какие видите слабые места для надежности?», «как в этом случае лучше организовать CDC?», …)
36 |     3. Контекст: схемы/диаграммы/описания, которые помогут разобраться в задаче, по крайней мере погрузиться в нее. Можно разместить ссылки на сторонние файлы и ресурсы.
37 | 
38 | *Мы не ограничены обсуждением в чате и можем дополнительно организовать как онлайн, так и очные встречи для обсуждения кейсов*
39 | 
40 | ## Правила группы
41 | 
42 | За любой переход на личности, любую агрессию, любые оскорбления - сразу бан.
43 | 
44 | Если видите нарушение, просьба тегнуть [@sergey486](https://t.me/sergey486) (или написать в личку).
45 | 
46 | ## Вопросы и ответы
47 | 
48 | **Что, если обсуждение уходит в сторону?**
49 | 
50 | - Любой из участников может предложить продолжить обсуждение интересующей его темы, не релевантной кейсу, в топике «[Флудилка](https://t.me/archicases/133)»
51 | - Автор кейса может сообщить, что обсуждение ушло в сторону и нерелевантно для него в настоящий момент и предложить продолжить обсуждение в топике «[Флудилка](https://t.me/archicases/133)»
52 | - Если обсуждаемая тема для вас релевантна в рамках вашего текущего рабочего кейса, чтобы не потерять информацию в потоке флудилки, можете написать @sergey486 с просьбой создать отдельный топик для обсуждаемой темы
53 | 
54 | Зачем?
55 | 
56 | - Не останавливать на полуслове обсуждение, а предложить место для его продолжения
57 | - Не терять ценных обсуждений, пусть и не относящихся к изначальной теме
58 | - В основном топике кейса оставить только релевантные кейсу обсуждения, чтобы топик содержал концентрированную и сфокусированную информацию именно по кейсу
59 | 
60 | **Как при описании кейса сохранить коммерческую тайну?**
61 | 
62 | Варианты:
63 | 
64 | 1. Не называть компанию, просто некая ООО Ромашка, работает в такой-то сфере,
65 | 2. Что-то изменить в контексте, добавить или убавить так, чтобы компанию это не компрометировало, но суть проблемы не исказило (самый сложный вариант),
66 | 3. Дать в начале более абстрактный контекст, если его недостаточно, добавлять понемногу в процессе обсуждения,
67 | 4. Рассматривать контекст с переменными, типа в компании или 10 человек, или 500. Решения соответственно тоже будут с ветвлениями
68 | 5. Попросить @sergey486 публиковать все обезличенно, через «нам в редакцию написали…»
69 | 
70 | 


--------------------------------------------------------------------------------
/archetypes/default.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "{{ replace .Name "-" " " | title}}"
3 | date: {{ .Date }}
4 | description: ""
5 | tags: []
6 | ShowToc: true
7 | ShowBreadCrumbs: true
8 | draft: false
9 | ---


--------------------------------------------------------------------------------
/assets/css/extended/backlinks.css:
--------------------------------------------------------------------------------
1 | .backlinks a {
2 |     box-shadow: 0 1px;
3 | }


--------------------------------------------------------------------------------
/assets/css/extended/dracula.css:
--------------------------------------------------------------------------------
  1 | /* Background */
  2 | .bg {
  3 |     color: #f8f8f2;
  4 |     background-color: #282a36;
  5 | }
  6 | 
  7 | /* PreWrapper */
  8 | .chroma {
  9 |     color: #f8f8f2;
 10 |     background-color: #282a36;
 11 | }
 12 | 
 13 | /* Other */
 14 | .chroma .x {}
 15 | 
 16 | /* Error */
 17 | .chroma .err {}
 18 | 
 19 | /* CodeLine */
 20 | .chroma .cl {}
 21 | 
 22 | /* LineTableTD */
 23 | .chroma .lntd {
 24 |     vertical-align: top;
 25 |     padding: 0;
 26 |     margin: 0;
 27 |     border: 0;
 28 | }
 29 | 
 30 | /* LineTable */
 31 | .chroma .lntable {
 32 |     border-spacing: 0;
 33 |     padding: 0;
 34 |     margin: 0;
 35 |     border: 0;
 36 | }
 37 | 
 38 | /* LineHighlight */
 39 | .chroma .hl {
 40 |     background-color: #474733
 41 | }
 42 | 
 43 | /* LineNumbersTable */
 44 | .chroma .lnt {
 45 |     white-space: pre;
 46 |     user-select: none;
 47 |     margin-right: 0.4em;
 48 |     padding: 0 0.4em 0 0.4em;
 49 |     color: #7f7f7f
 50 | }
 51 | 
 52 | /* LineNumbers */
 53 | .chroma .ln {
 54 |     white-space: pre;
 55 |     user-select: none;
 56 |     margin-right: 0.4em;
 57 |     padding: 0 0.4em 0 0.4em;
 58 |     color: #7f7f7f
 59 | }
 60 | 
 61 | /* Line */
 62 | .chroma .line {
 63 |     display: flex;
 64 | }
 65 | 
 66 | /* Keyword */
 67 | .chroma .k {
 68 |     color: #ff79c6
 69 | }
 70 | 
 71 | /* KeywordConstant */
 72 | .chroma .kc {
 73 |     color: #ff79c6
 74 | }
 75 | 
 76 | /* KeywordDeclaration */
 77 | .chroma .kd {
 78 |     color: #8be9fd;
 79 |     font-style: italic
 80 | }
 81 | 
 82 | /* KeywordNamespace */
 83 | .chroma .kn {
 84 |     color: #ff79c6
 85 | }
 86 | 
 87 | /* KeywordPseudo */
 88 | .chroma .kp {
 89 |     color: #ff79c6
 90 | }
 91 | 
 92 | /* KeywordReserved */
 93 | .chroma .kr {
 94 |     color: #ff79c6
 95 | }
 96 | 
 97 | /* KeywordType */
 98 | .chroma .kt {
 99 |     color: #8be9fd
100 | }
101 | 
102 | /* Name */
103 | .chroma .n {}
104 | 
105 | /* NameAttribute */
106 | .chroma .na {
107 |     color: #50fa7b
108 | }
109 | 
110 | /* NameBuiltin */
111 | .chroma .nb {
112 |     color: #8be9fd;
113 |     font-style: italic
114 | }
115 | 
116 | /* NameBuiltinPseudo */
117 | .chroma .bp {}
118 | 
119 | /* NameClass */
120 | .chroma .nc {
121 |     color: #50fa7b
122 | }
123 | 
124 | /* NameConstant */
125 | .chroma .no {}
126 | 
127 | /* NameDecorator */
128 | .chroma .nd {}
129 | 
130 | /* NameEntity */
131 | .chroma .ni {}
132 | 
133 | /* NameException */
134 | .chroma .ne {}
135 | 
136 | /* NameFunction */
137 | .chroma .nf {
138 |     color: #50fa7b
139 | }
140 | 
141 | /* NameFunctionMagic */
142 | .chroma .fm {}
143 | 
144 | /* NameLabel */
145 | .chroma .nl {
146 |     color: #8be9fd;
147 |     font-style: italic
148 | }
149 | 
150 | /* NameNamespace */
151 | .chroma .nn {}
152 | 
153 | /* NameOther */
154 | .chroma .nx {}
155 | 
156 | /* NameProperty */
157 | .chroma .py {}
158 | 
159 | /* NameTag */
160 | .chroma .nt {
161 |     color: #ff79c6
162 | }
163 | 
164 | /* NameVariable */
165 | .chroma .nv {
166 |     color: #8be9fd;
167 |     font-style: italic
168 | }
169 | 
170 | /* NameVariableClass */
171 | .chroma .vc {
172 |     color: #8be9fd;
173 |     font-style: italic
174 | }
175 | 
176 | /* NameVariableGlobal */
177 | .chroma .vg {
178 |     color: #8be9fd;
179 |     font-style: italic
180 | }
181 | 
182 | /* NameVariableInstance */
183 | .chroma .vi {
184 |     color: #8be9fd;
185 |     font-style: italic
186 | }
187 | 
188 | /* NameVariableMagic */
189 | .chroma .vm {}
190 | 
191 | /* Literal */
192 | .chroma .l {}
193 | 
194 | /* LiteralDate */
195 | .chroma .ld {}
196 | 
197 | /* LiteralString */
198 | .chroma .s {
199 |     color: #f1fa8c
200 | }
201 | 
202 | /* LiteralStringAffix */
203 | .chroma .sa {
204 |     color: #f1fa8c
205 | }
206 | 
207 | /* LiteralStringBacktick */
208 | .chroma .sb {
209 |     color: #f1fa8c
210 | }
211 | 
212 | /* LiteralStringChar */
213 | .chroma .sc {
214 |     color: #f1fa8c
215 | }
216 | 
217 | /* LiteralStringDelimiter */
218 | .chroma .dl {
219 |     color: #f1fa8c
220 | }
221 | 
222 | /* LiteralStringDoc */
223 | .chroma .sd {
224 |     color: #f1fa8c
225 | }
226 | 
227 | /* LiteralStringDouble */
228 | .chroma .s2 {
229 |     color: #f1fa8c
230 | }
231 | 
232 | /* LiteralStringEscape */
233 | .chroma .se {
234 |     color: #f1fa8c
235 | }
236 | 
237 | /* LiteralStringHeredoc */
238 | .chroma .sh {
239 |     color: #f1fa8c
240 | }
241 | 
242 | /* LiteralStringInterpol */
243 | .chroma .si {
244 |     color: #f1fa8c
245 | }
246 | 
247 | /* LiteralStringOther */
248 | .chroma .sx {
249 |     color: #f1fa8c
250 | }
251 | 
252 | /* LiteralStringRegex */
253 | .chroma .sr {
254 |     color: #f1fa8c
255 | }
256 | 
257 | /* LiteralStringSingle */
258 | .chroma .s1 {
259 |     color: #f1fa8c
260 | }
261 | 
262 | /* LiteralStringSymbol */
263 | .chroma .ss {
264 |     color: #f1fa8c
265 | }
266 | 
267 | /* LiteralNumber */
268 | .chroma .m {
269 |     color: #bd93f9
270 | }
271 | 
272 | /* LiteralNumberBin */
273 | .chroma .mb {
274 |     color: #bd93f9
275 | }
276 | 
277 | /* LiteralNumberFloat */
278 | .chroma .mf {
279 |     color: #bd93f9
280 | }
281 | 
282 | /* LiteralNumberHex */
283 | .chroma .mh {
284 |     color: #bd93f9
285 | }
286 | 
287 | /* LiteralNumberInteger */
288 | .chroma .mi {
289 |     color: #bd93f9
290 | }
291 | 
292 | /* LiteralNumberIntegerLong */
293 | .chroma .il {
294 |     color: #bd93f9
295 | }
296 | 
297 | /* LiteralNumberOct */
298 | .chroma .mo {
299 |     color: #bd93f9
300 | }
301 | 
302 | /* Operator */
303 | .chroma .o {
304 |     color: #ff79c6
305 | }
306 | 
307 | /* OperatorWord */
308 | .chroma .ow {
309 |     color: #ff79c6
310 | }
311 | 
312 | /* Punctuation */
313 | .chroma .p {}
314 | 
315 | /* Comment */
316 | .chroma .c {
317 |     color: #6272a4
318 | }
319 | 
320 | /* CommentHashbang */
321 | .chroma .ch {
322 |     color: #6272a4
323 | }
324 | 
325 | /* CommentMultiline */
326 | .chroma .cm {
327 |     color: #6272a4
328 | }
329 | 
330 | /* CommentSingle */
331 | .chroma .c1 {
332 |     color: #6272a4
333 | }
334 | 
335 | /* CommentSpecial */
336 | .chroma .cs {
337 |     color: #6272a4
338 | }
339 | 
340 | /* CommentPreproc */
341 | .chroma .cp {
342 |     color: #ff79c6
343 | }
344 | 
345 | /* CommentPreprocFile */
346 | .chroma .cpf {
347 |     color: #ff79c6
348 | }
349 | 
350 | /* Generic */
351 | .chroma .g {}
352 | 
353 | /* GenericDeleted */
354 | .chroma .gd {
355 |     color: #ff5555
356 | }
357 | 
358 | /* GenericEmph */
359 | .chroma .ge {
360 |     text-decoration: underline
361 | }
362 | 
363 | /* GenericError */
364 | .chroma .gr {}
365 | 
366 | /* GenericHeading */
367 | .chroma .gh {
368 |     font-weight: bold
369 | }
370 | 
371 | /* GenericInserted */
372 | .chroma .gi {
373 |     color: #50fa7b;
374 |     font-weight: bold
375 | }
376 | 
377 | /* GenericOutput */
378 | .chroma .go {
379 |     color: #44475a
380 | }
381 | 
382 | /* GenericPrompt */
383 | .chroma .gp {}
384 | 
385 | /* GenericStrong */
386 | .chroma .gs {}
387 | 
388 | /* GenericSubheading */
389 | .chroma .gu {
390 |     font-weight: bold
391 | }
392 | 
393 | /* GenericTraceback */
394 | .chroma .gt {}
395 | 
396 | /* GenericUnderline */
397 | .chroma .gl {
398 |     text-decoration: underline
399 | }
400 | 
401 | /* TextWhitespace */
402 | .chroma .w {}


--------------------------------------------------------------------------------
/config.yml:
--------------------------------------------------------------------------------
  1 | baseURL: "https://example.org"
  2 | title: Архитектурные этюды
  3 | paginate: 5
  4 | theme: PaperMod
  5 | defaultContentLanguage: ru
  6 | 
  7 | enableInlineShortcodes: true
  8 | enableRobotsTXT: true
  9 | buildDrafts: true
 10 | buildFuture: true
 11 | buildExpired: true
 12 | enableEmoji: true
 13 | pygmentsUseClasses: true
 14 | # googleAnalytics: UA-123-45
 15 | 
 16 | minify:
 17 |   disableXML: true
 18 |   # minifyOutput: true
 19 | 
 20 | languages:
 21 |   ru:
 22 |     languageName: "Русский"
 23 |     weight: 1
 24 |     taxonomies:
 25 |       category: categories
 26 |       tag: tags
 27 |       series: series
 28 |     menu:
 29 |       main:
 30 |         - name: Архив
 31 |           url: archives
 32 |           weight: 5
 33 |         - name: Поиск
 34 |           url: search/
 35 |           weight: 10
 36 |         - name: Теги
 37 |           url: tags/
 38 |           weight: 10
 39 |         - name: Github
 40 |           url: https://github.com/ru-arc/archicases
 41 | outputs:
 42 |   home:
 43 |     - HTML
 44 |     - RSS
 45 |     - JSON
 46 | 
 47 | params:
 48 |   env: production # to enable google analytics, opengraph, twitter-cards and schema.
 49 |   description: "Архитектурные этюды"
 50 |   author: RASA
 51 | 
 52 |   defaultTheme: auto
 53 |   # disableThemeToggle: true
 54 |   ShowShareButtons: true
 55 |   ShowReadingTime: true
 56 |   # disableSpecial1stPost: true
 57 |   displayFullLangName: true
 58 |   ShowPostNavLinks: true
 59 |   ShowBreadCrumbs: true
 60 |   ShowCodeCopyButtons: true
 61 |   ShowRssButtonInSectionTermList: true
 62 |   ShowToc: true
 63 |   comments: false
 64 |   # images: ["papermod-cover.png"]
 65 | 
 66 |   profileMode:
 67 |     enabled: false
 68 |     title: PaperMod
 69 |     imageUrl: "#"
 70 |     imageTitle: my image
 71 |     # imageWidth: 120
 72 |     # imageHeight: 120
 73 |     buttons:
 74 |       - name: Archives
 75 |         url: archives
 76 |       - name: Tags
 77 |         url: tags
 78 | 
 79 |   homeInfoParams:
 80 |     Title: "Архитектурные этюды"
 81 |     Content: >
 82 |       Всем привет!
 83 | 
 84 |       Это Архитектурные этюды
 85 | 
 86 |   socialIcons:
 87 |     - name: github
 88 |       url: "https://github.com/ru-arc/archicases"
 89 |     - name: Rss
 90 |       url: "index.xml"
 91 | 
 92 |   # editPost:
 93 |   #   URL: "https://github.com/adityatelange/hugo-PaperMod/tree/exampleSite/content"
 94 |   #   Text: "Suggest Changes" # edit text
 95 |   #   appendFilePath: true # to append file path to Edit link
 96 | 
 97 |   # label:
 98 |   #     text: "Home"
 99 |   #     icon: icon.png
100 |   #     iconHeight: 35
101 | 
102 |   # analytics:
103 |   #     google:
104 |   #         SiteVerificationTag: "XYZabc"
105 | 
106 |   assets:
107 |     disableHLJS: true
108 |   #     favicon: "<link / abs url>"
109 |   #     favicon16x16: "<link / abs url>"
110 |   #     favicon32x32: "<link / abs url>"
111 |   #     apple_touch_icon: "<link / abs url>"
112 |   #     safari_pinned_tab: "<link / abs url>"
113 | 
114 |   # cover:
115 |   #     hidden: true # hide everywhere but not in structured data
116 |   #     hiddenInList: true # hide on list pages and home
117 |   #     hiddenInSingle: true # hide on single page
118 | 
119 |   # fuseOpts:
120 |   #     isCaseSensitive: false
121 |   #     shouldSort: true
122 |   #     location: 0
123 |   #     distance: 1000
124 |   #     threshold: 0.4
125 |   #     minMatchCharLength: 0
126 |   #     keys: ["title", "permalink", "summary", "content"]
127 | 
128 | markup:
129 |   goldmark:
130 |     renderer:
131 |       unsafe: true
132 |   highlight:
133 |     noClasses: false
134 |     # anchorLineNos: true
135 |     # codeFences: true
136 |     # guessSyntax: true
137 |     # lineNos: true
138 |     # style: monokai
139 | 
140 | privacy:
141 |   vimeo:
142 |     disabled: true
143 |     simple: true
144 | 
145 |   twitter:
146 |     disabled: true
147 |     enableDNT: true
148 |     simple: true
149 | 
150 |   instagram:
151 |     disabled: true
152 |     simple: true
153 | 
154 |   youtube:
155 |     disabled: true
156 |     privacyEnhanced: true
157 | 
158 | services:
159 |   instagram:
160 |     disableInlineCSS: true
161 |   twitter:
162 |     disableInlineCSS: true
163 | 


--------------------------------------------------------------------------------
/configTaxo.yml:
--------------------------------------------------------------------------------
 1 | timeout: 30000
 2 | enableInlineShortcodes: true
 3 | 
 4 | taxonomies:
 5 |   category: categories
 6 |   tag: tags
 7 |   series: series
 8 | 
 9 | privacy:
10 |   vimeo:
11 |     disabled: true
12 |     simple: true
13 | 
14 |   twitter:
15 |     disabled: true
16 |     enableDNT: true
17 |     simple: true
18 |     disableInlineCSS: true
19 | 
20 |   instagram:
21 |     disabled: true
22 |     simple: true
23 | 
24 |   youtube:
25 |     disabled: true
26 |     privacyEnhanced: true
27 | 


--------------------------------------------------------------------------------
/content/2023/03/2023031521421111_sign_check.md:
--------------------------------------------------------------------------------
 1 | ---
 2 | title: "Sign Check"
 3 | date: 2023-03-15T21:42:11+03:00
 4 | description: ""
 5 | tags: ["digital_signature"]
 6 | ShowToc: true
 7 | ShowBreadCrumbs: true
 8 | draft: false
 9 | ---
10 | # Организовать работу при периодической недоступности сторонних сервисов
11 | 
12 | ## Описание
13 | 
14 | Пользователи сервиса N иногда оставляют ЭЦП (усиленную, квалифицированную). Для проверки подлинности этой ЭЦП используется сервис check-sign, который часть проверки осуществляет с помощью сервиса nalog.ru. Схематично взаимодействие представлено ниже:
15 | 
16 | - microservice N взаимодействует с check-sign через сообщения в kafka. Топик "check-sign" - запрос на проверку, "success" - успешная проверка, "fail" - неуспешная
17 | - сервис check-sign для отказоустойчивости развернут в 3 репликах. количество под может быть автоматически увеличено под нагрузкой
18 | - взаимодействие check-sign и nalog.ru - через REST API, другие способы интеграции отсутствуют
19 | - RPC: 1 000 000 проверок в сутки (предполагается, что на 1 проверку нужен 1 запрос)
20 | 
21 | Проблемой является периодическая недоступность сервиса nalog.ru. Требуется реализовать возможность накопить сообщения и, когда сервис восстановится, закончить проверку.
22 | 
23 | ## Предложенные решения
24 | 
25 | ### Решение 1
26 | 
27 | Необработанные подписи складываются в БД. Внешний шедулер периодически вызывает запрос на "переотправку" проблемных подписей.
28 | Проблему с одновременным доступом (concurrent access) на чтение, которую уже захватил другой поток, и использовать конструкцию for update skip locked (или аналогичную), таким образом 2 потока не прочитают одну и ту же запись.
29 | 
30 | ### Решение 2
31 | 
32 | Необработанные подписи отправляются в топик DLQ. Из этого топика чтение происходит с задержкой и пачками по N записей.
33 | 
34 | **Минусы**
35 | 
36 | - Еще один топик
37 | 
38 | ### Решение 3
39 | 
40 | Необработанные подписи возвращаются в тот же топик. Чтобы не попасть в бесконечный цикл, на сервисе check-sign необходимо реализовать предохранитель
41 | 
42 | Минусы
43 | 
44 | - Придется кодить предохранитель
45 | 
46 | ### Решение 4
47 | 
48 | Обработка подписей из топика Кафки останавливается, когда сервис nalog.ru недоступен. Когда nalog.ru восстанавливается, обработка подписей продолжается. Прочитанное сообщение не коммитится, пока подпись не будет обработана.  
49 | Если при обработке подписи nalog.ru несколько раз присылает невалидный ответ (но сам сервис доступен), то сообщение коммитится и перезаписывается в конец очереди (чтобы не задерживать обработку сообщений).
50 | 
51 | **Минусы**
52 | 
53 | - Может не сохраняться порядок обработки подписей
54 | 
55 | ## Источники
56 | 
57 | [GitHub: sign-check-case](https://github.com/froozer/sign-check-case/blob/main/README.md)
58 | [Архитектурные этюды: case#4: sign-check-case](https://t.me/archicases/1111)
59 | 


--------------------------------------------------------------------------------
/content/2023/04/2023042606481565_http_load_balancer.jpg:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/ru-arc/archicases/912350e8fd6fd029bc09c313da275ae680b6851f/content/2023/04/2023042606481565_http_load_balancer.jpg


--------------------------------------------------------------------------------
/content/2023/04/2023042606481565_http_load_balancer.md:
--------------------------------------------------------------------------------
 1 | ---
 2 | title: "Http Load Balancer"
 3 | date: 2023-04-26T06:48:15+03:00
 4 | description: ""
 5 | tags: ["system_design"]
 6 | ShowToc: true
 7 | ShowBreadCrumbs: true
 8 | draft: false
 9 | ---
10 | # Выбор HTTP-балансировщика нагрузки
11 | 
12 | ## Описание
13 | 
14 | Есть существующее решение. В нем внешние системы общаются с инстансами приложения напрямую (p2p). Инстансы приложения иногда падают. Требуется выбрать балансировщик нагрузки и поставить его между внешними системами и внутреними приложенниями (см изображение).
15 | 
16 | Вопросы:
17 | 1. На что обратить внимание при выборе балансировщика?
18 | 2. Какой балансировщик посоветуете под такую архитектуру и почему?
19 | 3. Какой точно не посоветуете под такую архитектуру и почему?
20 | 
21 | Внешние системы – они совсем внешние, это внешние партнеры, например.
22 | 
23 | ![Схема с балансировщиком](2023042606481565_http_load_balancer.jpg)
24 | 
25 | ## Уточнения
26 | 
27 | В ходе обсуждения был сформулирован перечень дополнительных вопросов, играющих существенную роль в выборе балансировщика нагрзуки:
28 | 
29 | 
30 | |Вопрос                          |Ответ автора кейса          |
31 | |--------------------------------|-----------------------------|
32 | |Какая нагрузка ожидается? 100rps, 1000rps, 100000rps             |6000+ rps           |
33 | |Сколько длится обработка запроса (10ms, 100ms, 1000ms, 10000ms)|10ms, ответ давать не требуется |
34 | |Кто (внешние системы или балансировщик) отвечают за повтор запросов при сбоях?|Внешние системы|
35 | |Где все развернуто (публичное облако, свое облако, не облако)?|не облако|
36 | |Нужна ли балансировка между ДЦ или все внутри ДЦ?|это два разных решения, нужны оба, но можно рассмотреть по отдельности, так как живут они отдельно|
37 | |Есть ли какие-то дополнительные правила на балансировке (sticky sessions, разметка для канарейки и т.п.)?|нет, только дополнение запроса айпишником отправителя|
38 | |Нужна ли доп.функциональность на балансировщике - авторизация, аутентификация, терминирование tls, биллинг, бюджетирование и так далее?|нет, аутентификация идет по login/pass, для пары login/pass сверяется ip-адрес|
39 | |Какие алгоритмы балансировки нужны - round-robin, взвешенная, на основе скорости отклика?|пока не ясно, надо экспериментировать, сейчас цель - поставить между партнерами и внутренними системами прослойку с возможностью балансировки максимально без усилий (без самописов и изменения существующих систем)|
40 | |Какие решения уже эксплуатируются в компании?| Никакие |
41 | |По каким решениям в команде есть эспертиза?| Nginx |
42 | 
43 | ## Предложенные решения
44 | 
45 | Значительно усложняет выбор сочетание необходимости повторов запросов балансировщиком и потребность в балансировке между различными датацентрами. Nginx из коробки так не умеет, однако в описанном кейсе за повторы отвечают сами внешние системы.
46 | 
47 | ### Решение 1
48 | 
49 | С указанными требованиями справится любой балансировщик. 
50 | Nginx, – удовлетворяет всем требованиям.
51 | 
52 | **Проблемы**
53 | Сложность в HA между датацентрами и  внутри датацентра.
54 | Из коробки Nginx не умеет балансировку между датацентрами, как решение можно использовать стандартный линуксовый механизм для HA (High Availability)
55 | 
56 | **Ссылки**
57 | 
58 | [Nginx HA](https://www.nginx.com/products/nginx/high-availability/)
59 | 
60 | 
61 | ### Решение 2
62 | Делегировать выбор тем инженерам, кто будет отвечать за эксплуатацию и достижение/поддержание заданных показателей. 
63 | 
64 | ### Обсуждение
65 | 
66 | https://t.me/archicases/1564/1565
67 | 
68 | 


--------------------------------------------------------------------------------
/content/2023/04/2023042919261345_microservice_api_testing_strategy.md:
--------------------------------------------------------------------------------
 1 | ---
 2 | title: "Стратегия тестирования API микросервисов"
 3 | date: 2023-04-29T19:26:13+03:00
 4 | description: ""
 5 | tags: []
 6 | ShowToc: true
 7 | ShowBreadCrumbs: true
 8 | draft: false
 9 | ---
10 | # Стратегия тестирования API микросервисов
11 | ## Описание
12 | Мы сейчас находимся в ситуации распределенного монолита. Тестирование представлено только юнит тестами (включающими обращения к базам) и системное тестирование через UI, в котором прогоняются сквозные сценарии. Все это приводит к тому, что мы не можем независимо выпускать сервисы.
13 | У нас 2 довольно крупных монолита и порядка 40 микросервисов. Большинство из них скорее вспомогательные. Но мы активно делим монолиты, и хочется сделать так, чтобы выделенные куски выпускались независимо.
14 | 
15 | ## Решения
16 | ### Решение 1
17 | Тестировать сервис используя АПИ моки (напр. wiremock), написать 80%-90% тестов. Остальное – сквозные интегрционные тесты в окружении, приближенном к боевому. Моки для каждого сервиса создаются авторами этого сервиса.
18 | 
19 | Плюсы:
20 | - Не нужно поднимать все требуемые сервисы
21 | 
22 | Минусы:
23 | - Нужно поддерживать моки
24 | 
25 | ### Решение 2
26 | Тестировать сервис используя АПИ моки, 20%-40% тестов. Часть тестов сквозные интегрционные тесты в окружении, приближенном к боевому, часть тестов в реальном окружении.
27 | 
28 | Плюсы:
29 | - Более "реальное" окружение для тестов
30 | 
31 | Минусы:
32 | - Необходимо поднимать полное окружение. Нужна хорошая автоматизация для тестового'локального энвайромента
33 | 
34 | ### Решение 3
35 | Использовать различные стратегии для разных сервисов.
36 | 
37 | > Обычно в продукте можно выделить два-три типа сервисов с разным подходом к тестированию:
38 | > 1) Доменные. Отвечают за логику отдельного субдомена. Зависимостей с другими доменами мало, эти зависимости легко мокаются или заменяются на эмуляторы (эмулятор - это быстрая стандартная заглушка, написанная автором сервиса, нужная для простых и быстрых тестов контрактов). Тестировать лучше как "черный ящик", с подключенной базой данных.
39 | > 2) Интеграционные. Отвечают за междоменную логику, обычно где-то рядом с UI или со сложными сценариями.
40 |      К ним относятся разные bff, реализация сложных междоменных саг и так далее.
41 |      Их реально сложно тестировать на заглушках, проще тестировать на реальном взаимодействии. Но самих таких сервисов мало и функциональности в них должно быть мало.
42 |      Если их тестировать "изолировано" - то полностью на моках.
43 | > 3) Адаптеры. Про взаимодействие с внешними системами.
44 |      Для целей "внутри" легко заменяются на эмулятор или вообще /dev/null (обычно это только исходящие или входящие потоки), при тестировании обычно важно проверять, насколько "внешний мир" соответствует представлениям сервиса о нем. Это как раз про отправку SMS.
45 | 
46 | ## Источники
47 | [Case 7: тестирование микросрвисов](https://t.me/archicases/1345)
48 | 
49 | ## Ссылки
50 | [Статья о тестировании микросервисов](https://agilemindset.ru/тестирование-микросервисов/)
51 | 


--------------------------------------------------------------------------------
/content/2023/05/20230506160801-1.jpg:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/ru-arc/archicases/912350e8fd6fd029bc09c313da275ae680b6851f/content/2023/05/20230506160801-1.jpg


--------------------------------------------------------------------------------
/content/2023/05/20230506160801-one-time-passwords.md:
--------------------------------------------------------------------------------
 1 | ---
 2 | title: "One Time Passwords"
 3 | date: 2023-05-06T16:08:01+03:00
 4 | description: ""
 5 | tags: []
 6 | ShowToc: true
 7 | ShowBreadCrumbs: true
 8 | draft: false
 9 | ---
10 | # Реализация одноразовых паролей
11 | 
12 | ## Контекст проблемы
13 | 
14 | Меня активно пытаются поломать прямо сейчас. И я подумал, а как можно решить такую проблему? Ведь явно архитектурная задача.
15 | 
16 | Описание:
17 | 
18 | - есть сервис и подтверждение операций по одноразовому коду
19 | - кто-то раз в какое-то время, вот как здесь раз в час что-то пытается сделать и мне прилетает одноразовы пароль
20 | - когда мне потребуется что-то подтвердить самому, я могу случайно использовать одноразовый пароль злоумышленника, если так совпадет, что он запросит права в то же самое время
21 | 
22 | Как блокировать - непонятно, айпишник может быть динамическим.
23 | 
24 | Можно указывать в письме на какое действие этот одноразовый код, но это сильно усложняет решение.
25 | 
26 | Какие вообще есть опции?
27 | 
28 | ![](20230506160801-1.jpg)
29 | 
30 | ## Предложенные решения
31 | 
32 | ### TOTP
33 | 
34 | Перенести создание одноразовых паролей на сторону клиента, сервер лишь ожидает подтверждение операции путём ввода кода клиентом.
35 | 
36 | Один из возможных вариантов реализации это [Time-based One Time Password(TOTP)](https://en.wikipedia.org/wiki/Time-based_one-time_password). Приложения Google authenticator, Microsoft authenticator.
37 | 
38 | TOTP независим от канала связи с интернет.
39 | Из независимости от связи TOTP следует и его же главный недостаток - нет привязки кода к подтверждаемой сессии, то есть код TOTP подходит для подтверждения любой операции в текущий момент.
40 | 
41 | TOTP может быть сложен в применении для рядовых пользователей.
42 | 
43 | ### OCRA
44 | 
45 | Алгоритм [RFC-6237 OCRA](https://datatracker.ietf.org/doc/html/rfc6287), основан на TOTP, но требует наличие challenge от сервера. Так можно привязать код аутентификации к конкретной сессии сервера.
46 | 
47 | Недостаток OCRA в том что он требует быть онлайн.
48 | 
49 | ### Аппаратное устройство аутентификации
50 | 
51 | Например токен [YubiKey](https://www.yubico.com/products/), смарт-карты, и аппратные устройства, в том числе биометрические датчики.
52 | 
53 | Подтвердить операцию невозможно без обладания физическим устройством.
54 | Сессия аутентфиикации может быть связана с конкретной подтверждаемой операцией  — зависит от реализации прикладной системы.
55 | 
56 | Как правило аппаратное устройства защищено PIN-кодом или биометрическим датчиком, то есть для аутентификации требуется физическое устройство и пароль или биометрический отпечаток к нему.
57 | 
58 | Это лучший с точки зрения безопасности вариант,
59 | однако применение аппаратного устройства возможно не во всех пользовательских сценариях, а так же требуется реализация поддержки протоколов Web Authentication API или FIDO2 в прикладной системе.
60 | 
61 | ## Заключение
62 | 
63 | При любом выбранном варианте реализации важно:
64 | 
65 | * Одноразовый код должен быть привязан к конкретной операции
66 | * Если код генерируется сервером, то в сообщении клиенту должны присутствовать идентификатор и краткое описание подтверждаемой операции, например "Вход в учетную запись", "Платеж 100руб Паркинг №123"
67 | * Проверка одноразового кода всегда производится в рамках действующей сессии основной авторизации, то проверяется так же наличие основной действующей авторизации (логина-пароля).
68 | * В сообщениях клиенту нежелательно использовать код в виде гиперссылок, клиент может нажать не глядя
69 | 
70 | ## Источник
71 | 
72 | [11: одноразовые пароли](https://t.me/archicases/1644)
73 | 
74 | ## Тестируем гиперссылки
75 | 
76 | * [Реализация одноразовых паролей](/content/2023/05/20230506160801-one-time-passwords.md)
77 | 


--------------------------------------------------------------------------------
/content/2023/05/2023052517181717_surrogate_keys.md:
--------------------------------------------------------------------------------
 1 | ---
 2 | title: "Surrogate Keys"
 3 | date: 2023-05-25T18:18:17:17+03:00
 4 | description: ""
 5 | tags: ["db", "db_keys"]
 6 | ShowToc: true
 7 | ShowBreadCrumbs: true
 8 | draft: false
 9 | ---
10 | # Суррогатные ключи в базах
11 | 
12 | ## Описание 
13 | 
14 | Есть 4 независимых установки со своими базами. В каждой есть свои собственные auto_increment ключи.
15 | 
16 | Запускаем CDC-решение на дебезиуме.
17 | Нужно слить из 4 независимых баз данные в одну и ключи в этих базах пересекаются, что ломает весь процесс.
18 | 
19 | Какие существуют варианты решения такой проблемы?
20 | 
21 | ## Предложенные решения
22 | 
23 | ## Решение 1
24 | 
25 | Если таблицы пересекаются, то в пересекающихся таблицах вводится суррогатный ключ и фиксируется источник каждой строки. 
26 | Получается композитный индекс <key, shard>.
27 | 
28 | ## Решение 2
29 | 
30 | Вводится новый ключ, при этом «бывший» ключ будет «обычным» атрибутом и перестанет играть роль ключа.
31 | Для нового ключа можно задать префикс по системе источника <source_newKey>
32 | 
33 | ### Особенность решений
34 | Если не требуется выборки по системам-источникам, то признак системы-источника можно не хранить и тогда решение 
35 | упрощается до ввода нового суррогатного ключа без префикса.
36 | 
37 | ### Обсуждение
38 | 
39 | https://t.me/archicases/1716/1717
40 | 


--------------------------------------------------------------------------------
/content/2023/05/2023053020281611_online_widget_telegram_bot.md:
--------------------------------------------------------------------------------
 1 | ---
 2 | title: "Архитектура онлайн-виджета на сайте"
 3 | date: 2023-05-30T20:28:16+03:00
 4 | description: ""
 5 | tags: []
 6 | ShowToc: true
 7 | ShowBreadCrumbs: true
 8 | draft: false
 9 | ---
10 | # Архитектура онлайн-виджета на сайте
11 | ## Описание
12 | Добрый вечер!
13 | Недавно я прочитал серию статей на Хабре, где разработчик запилил виджет для сайта типа jivo, который общается с телегой.
14 | Я подумал, что было бы интересно разобрать этот проект как архитектурный этюд.
15 | Эта статья посвящена архитектуре
16 | https://habr.com/ru/articles/723412/
17 | Он пишет, что бывают сайты, у которых проходимость 100 000 посетителей в день и им часто пишет параллельно 5-10 пользователей.
18 | Для таких сайтов, к сожалению, в целом Telegram не подойдет и у них сообщения действительно будут тормозить. В таком случае я говорю прямо, что со мной в рамках их задач работать будет неудобно.
19 | Вот мне интересно так ли это или можно решить это? Например группируя сообщения в течение небольшого интервала, а потом уже отправляя в телегу?
20 | Далее он пишет, что есть ограничение на отправку 40 сообщений в секунду во все чаты на одного бота, и что это возможная проблема в будущем. Также он написал, что подготовил набросок решения в виде подключения новых ботов и их балансировки.
21 | Кажется, что это уже частичное решение проблемы выше?
22 | Также было бы интересно разобрать альтернативные подходы к созданию такого виджета.
23 | 
24 | ## Решение
25 | Зарегистрировать N ботов и организовать одновременную привязку 40 пользователей к 1 боту.
26 | 
27 | Плюсы:
28 | - Самое простое решение из доступных
29 | 
30 | Минусы:
31 | - Нужно регистрировать N ботов, сомнительный UX при переписке в телеграмме (не через виджет на сайте)


--------------------------------------------------------------------------------
/content/archives.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "Архив"
3 | layout: "archives"
4 | # url: "/archives"
5 | summary: "archives"
6 | ---


--------------------------------------------------------------------------------
/content/search.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "Поиск"
3 | layout: "search"
4 | ---


--------------------------------------------------------------------------------
/layouts/_default/single.html:
--------------------------------------------------------------------------------
 1 | {{- define "main" }}
 2 | 
 3 | <article class="post-single">
 4 |   <header class="post-header">
 5 |     {{ partial "breadcrumbs.html" . }}
 6 |     <h1 class="post-title">
 7 |       {{ .Title }}
 8 |       {{- if .Draft }}<sup><span class="entry-isdraft">&nbsp;&nbsp;[draft]</span></sup>{{- end }}
 9 |     </h1>
10 |     {{- if .Description }}
11 |     <div class="post-description">
12 |       {{ .Description }}
13 |     </div>
14 |     {{- end }}
15 |     {{- if not (.Param "hideMeta") }}
16 |     <div class="post-meta">
17 |       {{- partial "post_meta.html" . -}}
18 |       {{- partial "translation_list.html" . -}}
19 |       {{- partial "edit_post.html" . -}}
20 |       {{- partial "post_canonical.html" . -}}
21 |     </div>
22 |     {{- end }}
23 |   </header>
24 |   {{- $isHidden := .Params.cover.hidden | default site.Params.cover.hiddenInSingle | default site.Params.cover.hidden }}
25 |   {{- partial "cover.html" (dict "cxt" . "IsHome" false "isHidden" $isHidden) }}
26 |   {{- if (.Param "ShowToc") }}
27 |   {{- partial "toc.html" . }}
28 |   {{- end }}
29 | 
30 |   {{- if .Content }}
31 |   <div class="post-content">
32 |     {{- if not (.Param "disableAnchoredHeadings") }}
33 |     {{- partial "anchored_headings.html" .Content -}}
34 |     {{- else }}{{ .Content }}{{ end }}
35 |   </div>
36 |   {{- end }}
37 | 
38 |   <footer class="post-footer">
39 |     {{- $tags := .Language.Params.Taxonomies.tag | default "tags" }}
40 | 
41 |     {{ partial "backlinks.html" (dict "page" .) }}
42 | 
43 |     <ul class="post-tags">
44 |       {{- range ($.GetTerms $tags) }}
45 |       <li><a href="{{ .Permalink }}">{{ .LinkTitle }}</a></li>
46 |       {{- end }}
47 |     </ul>
48 |   </footer>
49 | 
50 |   {{- if (.Param "comments") }}
51 |   {{- partial "comments.html" . }}
52 |   {{- end }}
53 | </article>
54 | 
55 | {{- end }}{{/* end main */}}


--------------------------------------------------------------------------------
/layouts/partials/backlinks.html:
--------------------------------------------------------------------------------
 1 | {{ $backlinks := slice }}
 2 | {{ $path_base := .page.File.ContentBaseName }}
 3 | {{ $path_base_re := printf `["/(]%s["/)]` $path_base }}
 4 | 
 5 | {{ range where site.RegularPages "RelPermalink" "ne" .page.RelPermalink }}
 6 |     {{ if (findRE $path_base_re .RawContent 1) }}
 7 |         {{ $backlinks = $backlinks | append . }}
 8 |     {{ end }}
 9 | {{ end }}
10 | 
11 | {{ with $backlinks }}
12 |     <section class="backlinks">
13 |         {{ printf "%s" ($.heading | default "<h2>Обратные ссылки</h2>") | safeHTML }}
14 |         <nav>
15 |             <ol>
16 |                 {{ range . }}
17 |                     <li>
18 |                         <a href="{{ .RelPermalink }}">{{ .Title }}</a>
19 |                     </li>
20 |                 {{ end }}
21 |             </ol>
22 |         </nav>
23 |     </section>
24 | {{ end }}


--------------------------------------------------------------------------------
/linear_cases_list.md:
--------------------------------------------------------------------------------
1 | # Линейный список дайджестов кейсов
2 | 
3 | [Организовать работу при периодической недоступности сторонних сервисов](cases/2023031521421111_sign_check.md)
4 | 
5 | [Выбор HTTP-балансировщика нагрузки](cases/2023042606481565_http_load_balancer.md)
6 | 
7 | [Суррогатные ключи в базах](cases/2023052517181717_surrogate_keys.md)
8 | 


--------------------------------------------------------------------------------
/static/img/case_http_load_balancer.jpg:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/ru-arc/archicases/912350e8fd6fd029bc09c313da275ae680b6851f/static/img/case_http_load_balancer.jpg


--------------------------------------------------------------------------------
/template.md:
--------------------------------------------------------------------------------
 1 | # Название проблемы
 2 | 
 3 | ## Бизнес-кейс
 4 | 
 5 | 
 6 | **Бизнес-драйверы**
 7 | 
 8 |  * Драйвер
 9 |  * Драйвер
10 |  * Драйвер
11 | 
12 | **Бизнес-цели**
13 | 
14 |  * Цель
15 | 
16 | ## Требования
17 | 
18 | ### Заинтересованные лица
19 | 
20 | * **Заинтересованное лицо**
21 |   - Интерес
22 |   - Интерес
23 |   - Итерес
24 |   
25 |   
26 | ### Функциональные требования
27 | 
28 | * Требование
29 | * Требование
30 | * Требование
31 | 
32 | ### Архитектурные требования
33 | 
34 | * Требование
35 | * Требование
36 | * Требование
37 | 
38 | ### Дополнительный контекст
39 | 
40 | * Контекст
41 | * Контекст
42 | * Контекст
43 | 
44 | ## Целевая архитектура
45 | 
46 | 
47 | ## Анализ
48 | 
49 | ### Оценка стоимости
50 | 
51 | ### Оценка сроков
52 | 
53 | ### Оценка рисков
54 | 
55 | # ADRs
56 | 
57 | ## Название ADR
58 | 
59 | ### Рассмотренные альтернативы
60 | 
61 | **Альтернатива**
62 |  - Особенность
63 | 
64 | **Альтернатива**
65 |  - Особенность
66 | 
67 | **Альтернатива**
68 |  - Особенность
69 | 
70 | 
71 | ## Плюсы
72 | 
73 |  * 
74 | 
75 | 
76 | 
77 | ## Риски
78 | 
79 |  * 
80 | 
81 | 
82 | ## Стратегия
83 | 
84 |  * 
85 |    
86 |  
87 | 


--------------------------------------------------------------------------------