#advanced #architecture
Домены, поддомены, ограниченные контексты и другие понятия из мира DDD в большой обзорной статье.
https://medium.com/nick-tune-tech-strategy-blog/domains-subdomain-problem-solution-space-in-ddd-clearly-defined-e0b49c7b586c
Домены, поддомены, ограниченные контексты и другие понятия из мира DDD в большой обзорной статье.
https://medium.com/nick-tune-tech-strategy-blog/domains-subdomain-problem-solution-space-in-ddd-clearly-defined-e0b49c7b586c
Medium
Domain, Subdomain, Bounded Context, Problem/Solution Space in DDD: Clearly Defined
Domain-Driven Design is an approach to designing systems, usually software, that emphasises creating a common language between domain…
#architecture
Когда возникает вопрос о том, чтобы наша бизнес-сущность имела различные состояния, мы создаем у сущности поле state/status, которое помогает ориентироваться в том, как управлять сущностью и какие операции допустимы. Такой подход кажется не совсем удобным, когда бизнес-операции имеют важное значение в разное время жизни сущности. Во-первых, дублирование каких-то действий, если вы забыли проверить текущий статус, может сломать состояние модели (что если заказ будет оплачен 2 раза?). Во-вторых, у разных состояний разный набор бизнес-операций, а иногда – разный набор данных: где-то больше, где-то меньше. Было бы удобнее не держать все в одном месте, а делать на каждый статус отдельную таблицу. К сожалению, если вы не используете совместно с таким подходом CQRS, вам будет сложно работать с такой структурой при выборках данных. Есть и другой подход – отдельная таблица со статусами. Подробнее можно почитать по ссылке: https://dba.stackexchange.com/questions/158949/should-i-create-multiple-tables-for-different-entity-states-statuses-or-stages.
А расскажите про свой опыт управления сущностями с разными статусами в комментариях.
Когда возникает вопрос о том, чтобы наша бизнес-сущность имела различные состояния, мы создаем у сущности поле state/status, которое помогает ориентироваться в том, как управлять сущностью и какие операции допустимы. Такой подход кажется не совсем удобным, когда бизнес-операции имеют важное значение в разное время жизни сущности. Во-первых, дублирование каких-то действий, если вы забыли проверить текущий статус, может сломать состояние модели (что если заказ будет оплачен 2 раза?). Во-вторых, у разных состояний разный набор бизнес-операций, а иногда – разный набор данных: где-то больше, где-то меньше. Было бы удобнее не держать все в одном месте, а делать на каждый статус отдельную таблицу. К сожалению, если вы не используете совместно с таким подходом CQRS, вам будет сложно работать с такой структурой при выборках данных. Есть и другой подход – отдельная таблица со статусами. Подробнее можно почитать по ссылке: https://dba.stackexchange.com/questions/158949/should-i-create-multiple-tables-for-different-entity-states-statuses-or-stages.
А расскажите про свой опыт управления сущностями с разными статусами в комментариях.
Database Administrators Stack Exchange
Should I create multiple tables for different entity states, statuses or stages?
I have a tasks table in my database and, in the business domain of interest, tasks can have multiple states: “open”, “begun”, “in review” and “completed”.
Despite having “open” and “begun” in the s...
Despite having “open” and “begun” in the s...