Learning Domain-Driven Design: Aligning Software Architecture and Business Strategy

by Vladik Khononov

When discussing tactical design patterns, don’t appeal to authority: “Let’s use an aggregate here because the DDD book says so!” Instead, appeal to logic. For example: Why are explicit transactional boundaries important? To protect the consistency of the data. Why can’t a database transaction modify more than one instance of an aggregate? To ensure that the consistency boundaries are correct. Why can’t an aggregate’s state be modified directly by an external component? To ensure that all the related business logic is colocated and not duplicated. Why can’t we offload some of the aggregate’s functionality to a stored procedure? To make sure that no logic is duplicated. Duplicated logic, especially in logically and physically distant components of a system, tends to go out of sync and lead to data corruption. Why should we strive for small aggregate boundaries? Because wide transactional scope will both increase the complexity of the aggregate and negatively impact the performance. Why, instead of event sourcing, can’t we just write events to a logfile? Because there are no long-term data consistency guarantees.