#Domain-Driven-Design
16 notas · última:
Finding modules in a big ball of mud
The post argues that tangled code is normal and that modules should be found by reading dependency graphs, matrices, and domain neighborhoods rather than forcing an early architecture.
Thinking in Actors - Part 1
The post argues that web apps are better modeled around real business operations and stateful domain behavior than around CRUD, and presents the Actor Model and virtual actors as a way to handle concurrency, distribution, and fault tolerance.
Avoiding Identity Obsession in .NET with Entity Framework Core
Peter Ritchie shows how to configure EF Core shadow properties so a database-required primary key never leaks into a Domain-Driven Design entity's own model.
Domain-Driven Design meets Functional Programming
Interview with Scott Wlaschin on why DDD's demand for composable, autonomous subsystems fits functional programming better than OO does in practice.
Understanding Pure Domain Modelling
Argues that domain experts default to describing their existing system rather than the real domain, and proposes asking 'what would you do without a system?' to get past that bias.
How Domain-Driven Design Changed My Approach to AI agent architecture
The author says Domain-Driven Design changed how he sees software design, helping him isolate the core domain of an AI coding platform and model agents through events instead of direct calls.
Hexagonal Architecture from the Ground Up
The article contrasts layered architecture with hexagonal architecture and argues that ports and adapters keep domain logic at the center, make boundaries cleaner, and support easier testing and change.
Serverless Architecture Layers
The article proposes five serverless architecture layers for enterprises: experience, cross-cutting, domain, data, and platforms. It argues that clear boundaries, versioned interfaces, and shared governance reduce duplicated logic, cognitive load, and distributed monoliths.
Functional Patterns in Domain-Driven Design
The page says DDD benefits from a ubiquitous language, but class-based state-and-behavior models can become muddled and fragile. It presents standalone functions as a better fit for modular domain behavior.
Domain-Driven Design (DDD) With F# and EventStore
The post presents a DDD implementation in F# with EventStore, using functional constructs, discriminated unions, and fold-based event application to keep domain logic explicit and isolated from infrastructure.
What is the difference between DAO and Repository patterns?
The page contrasts DAO as a data-persistence abstraction, often closer to the database, with Repository as a collection-like abstraction tied to domain objects and aggregate roots, usually with a narrower interface.
DDD Aggregate
A DDD aggregate is a cluster of domain objects treated as one unit, with a single aggregate root handling outside references and integrity. Data is loaded and saved as whole aggregates, and transactions should not cross aggregate boundaries.
UbiquitousLanguage
Eric Evans uses “Ubiquitous Language” for the practice of building a common, rigorous language between developers and users, based on the domain model and changed as understanding of the domain grows.
Bounded Context
Bounded Context is a central DDD pattern for splitting large systems into separate models, each internally consistent, while making relationships between contexts explicit.
DDD – Introdução a Domain Driven Design
O artigo apresenta DDD como projeto orientado a domínio, mostra linguagem ubíqua e projeto dirigido pelo modelo, e reúne padrões para modelar, refinar e organizar sistemas complexos.
A Discussion on Domain Driven Design: Value Objects
The post explains Value Objects as domain concepts without identity, contrasted with Entities. It uses everyday examples and a family model to show how Attire belongs to Kid and must be changed through the owner.