Я только за проектирование снизу-вверх, ныне забытое и заброшенное
KISS, YAGNI, Functional Programming которое все это поощряет
FP вы просто пишите смысловую код не особо заботясь о связующей части. Когда понадобится вы легко ее свяжете. Вам не нужно как в ООП сороконожке думать в какой последовательности переставлять ваши 40 ног.
Особенно в гибких методах разработки, когда нужно создать прототип, когда нет четких требований и видения что будет меняться.
Но вот если у вас есть четкий план / ТЗ то давайте ка лучше будем смотреть на систему в целом и пойдем сверху-вниз. DRY, abstractions, polymorphism, low coupling high cohesion и прочие принципы, стремящиеся сдержать трудоемкость изменений при росте кодовой базы.
Не бойтесь рефакторинга, часто это проще чем пытаться предусмотреть все заранее. Главное, чтобы изменения не сломали вашу базу.
Что такое модули верхних уровней? Как определить этот уровень? Как оказалось, все очень просто. Чем ближе модуль к вводу/выводу, тем ниже уровень модуля. Т.е. модули, работающие с BD, интерфейсом пользователя, низкого уровня. А модули, реализующие бизнес-логику — высокого уровня.
не совсем
нижний уровень это взаимодействие: ввод-вывод, API, ...
почему нижний? потому что это привязано к контексту и значит тут наиболее часто изменяемый код
потом привязка к вариантам использования, т.е. блокам возможных входных сообщений и контекстов, это сервисный слой
самый верхний слой (домен) он не зависит от вариантов использования и самый редко изменяемый
итак, если хотите какую-то непрерывную меру то я бы выбрал "независимость от контекста и инструментов", чем меньше зависимость тем выше уровень
также можно использовать то что зависимость и управление идут рядом
если в бизнесе есть управляющий сервис, то он выше по абстракции
обслуживающие сервисы ниже по уровню абстракции и больше подвержены изменениям
class Recipe
ingredients: List[Ingredient]
description: str
class Ingredient
name: str
weight: float
class type Cookie
class Bread : Cookie
class MeatPie : Cookie
class PotatoPie : Cookie
class type IOven
class GasOven : IOven
class ElectricOven : IOven
state On | Off
class Gas
ovenOn IOven -> Gas -> state -> (IOven state)
cook : IOven state recipe-> Maybe Bread
а его уже можно перевести в шарп через ЧатГПТ код ибо никто на Хаскеле нынче не пишет
using System.Collections.Generic;
class Recipe
{
public List<Ingredient> ingredients;
public string description;
}
class Ingredient
{
public string name;
public float weight;
}
class Cookie { }
class Bread : Cookie { }
class MeatPie : Cookie { }
class PotatoPie : Cookie { }
interface IOven { }
class GasOven : IOven { }
class ElectricOven : IOven { }
enum State
{
On,
Off
}
class Gas { }
record OvenOnRequest (IOven oven, State state)
record CookRequest(IOven oven, State state, Recipe recipe)
class SomeShit
{
IOven ovenOn(IOven oven, State state, Gas gas)
{
...
}
Maybe<Bread> cook(IOven oven, State state, Recipe recipe)
{
return new Maybe<Bread>();
}
}
итого минут 10 на бумажке, не отлаживал
... ну или state засунуть внутрь IOven но лень
Блин, на перевод на шарп времени больше ушло исправлять за чатГПТ, да и то не уверен
я так и не понял, удалось денег поднять или нет?
деньги в моем ИТ окружении были 2006-08 а затем только после 2018 где-то
вот на эти 10 лет я уходил из профессии, потом вернулся
Чистая: для отрицательных возвращается NaN
на стейт машину
Так это проблемы openai
Много математики потребовало функциональное программирование.
А императивщина это так: тяп ляп
Автор сумасшедший экстраверт - трудоголик
Я так и не понял, в чем был успех и где радость жизни
Я только за проектирование снизу-вверх, ныне забытое и заброшенное
KISS, YAGNI, Functional Programming которое все это поощряет
FP вы просто пишите смысловую код не особо заботясь о связующей части. Когда понадобится вы легко ее свяжете. Вам не нужно как в ООП сороконожке думать в какой последовательности переставлять ваши 40 ног.
Особенно в гибких методах разработки, когда нужно создать прототип, когда нет четких требований и видения что будет меняться.
Но вот если у вас есть четкий план / ТЗ то давайте ка лучше будем смотреть на систему в целом и пойдем сверху-вниз. DRY, abstractions, polymorphism, low coupling high cohesion и прочие принципы, стремящиеся сдержать трудоемкость изменений при росте кодовой базы.
Не бойтесь рефакторинга, часто это проще чем пытаться предусмотреть все заранее. Главное, чтобы изменения не сломали вашу базу.
имелось в виду что ты не умеешь вычленять из монолита микросервисы и вообще их проектировать
судя по статье и не надо, лучше по Влашину строить нормальные домены а внутри их нормальные сервисы В МОНОЛИТЕ
горизонтально масштабировать можно БД
а вот аппликейшны не стоит: нынче ядер у процессоров столько что вы раньше упретесь в закон Амдала чем в железо
объекты то не нужны - ФП лучше
а уж object relation тем более
не совсем
нижний уровень это взаимодействие: ввод-вывод, API, ...
почему нижний? потому что это привязано к контексту и значит тут наиболее часто изменяемый код
потом привязка к вариантам использования, т.е. блокам возможных входных сообщений и контекстов, это сервисный слой
самый верхний слой (домен) он не зависит от вариантов использования и самый редко изменяемый
итак, если хотите какую-то непрерывную меру то я бы выбрал "независимость от контекста и инструментов", чем меньше зависимость тем выше уровень
также можно использовать то что зависимость и управление идут рядом
если в бизнесе есть управляющий сервис, то он выше по абстракции
обслуживающие сервисы ниже по уровню абстракции и больше подвержены изменениям
Можно ещё purchase state
А логику перехода между состояниями в чистые функции, которые не привязаны к конкретно классу
Наверняка
самое интересное - последняя четверть текста
я чуть не закрыл страницу
Да понятно все )))
Программа это большое логическое выражение, выраженное как бинарное дерево
Бинарное дерево состоит из листьев и ветвлений - это S I K комбинаторы
Йота комбинатор это рекурсия (самоприменение)
Йота язык программа как число) это свертка бинарного дерева
купил, мне не понравилось
первая половина про рефакторинг с целью устранения побочных эффектов и повышения переиспользования кода
вторая половина про какую то фигню с непонятной пользой
про то как проектировать приложение под ФП, под stateless я там не увидел
из плюсов там подача материала через UseCases простые и узнаваемые
хлипкий Хаселист попался
за синтаксис не поручусь, но и так все ясно
а его уже можно перевести в шарп через ЧатГПТ код ибо никто на Хаскеле нынче не пишет
итого минут 10 на бумажке, не отлаживал
... ну или state засунуть внутрь IOven но лень
Блин, на перевод на шарп времени больше ушло исправлять за чатГПТ, да и то не уверен
через расширения удобней
Точнее так (с учетом всего прочитанного тут) - только вот реализацию периметра не удается унаследовать о прямоугольника, а может и не нужно