Domain Driven Design - Jimmy Bogard

Sign in Subscribe

Domain Driven Design

A collection of 16 posts

A Service Boundary Homework Problem

I guess it was inevitable, but quite often I see homework problems on r/microservices seemingly assigned in some intro CS class. Peculiarities of that aside, they can be quite fun to work through as thought experiments. One recent one came up: Hi, I am working on a school app.

Domain Driven Design

Domain-Driven Refactoring: Encapsulating Collections

Posts in this series: * Intro * Procedural Beginnings * Long Methods * Extracting Domain Services * Defactoring and Pushing Behavior Down * Encapsulating Data * Encapsulating Collections In the last post, we looked at refactoring our domain model so that we have explicit entry points in order to mutate our domain object. I skipped one of

Domain Driven Design

Domain-Driven Refactoring: Encapsulating Data

Posts in this series: * Intro * Procedural Beginnings * Long Methods * Extracting Domain Services * Defactoring and Pushing Behavior Down * Encapsulating Data * Encapsulating Collections In the last post, we looked at using a few common refactorings to encapsulate operations and push behavior down into our domain model. While this works to encapsulate operations,

Domain Driven Design

Domain-Driven Refactoring: Defactoring and Pushing Behavior Down

Posts in this series: * Intro * Procedural Beginnings * Long Methods * Extracting Domain Services * Defactoring and Pushing Behavior Down * Encapsulating Data * Encapsulating Collections In the last post, we looked at our procedural handler and pulled behavior out that called to external services into its own domain service. This let our handler become

Domain Driven Design

Domain-Driven Refactoring: Extracting Domain Services

Posts in this series: * Intro * Procedural Beginnings * Long Methods * Extracting Domain Services * Defactoring and Pushing Behavior Down * Encapsulating Data * Encapsulating Collections In my last post, we looked at the Compose Method refactoring as a means of breaking up long methods into smaller ones, each with an equivalent level of granularity.

Domain Driven Design

Domain-Driven Refactoring: Long Methods

Posts in this series: * Intro * Procedural Beginnings * Long Methods * Extracting Domain Services * Defactoring and Pushing Behavior Down * Encapsulating Data * Encapsulating Collections In the last post, I walked through the main, immediate code smell we saw of a long method, and I would classify this method as long: public class AssignOfferHandler

Domain Driven Design

Domain-Driven Refactoring: Procedural Beginnings

Posts in this series: * Intro * Procedural Beginnings * Long Methods * Extracting Domain Services * Defactoring and Pushing Behavior Down * Encapsulating Data * Encapsulating Collections As part of the red-green-refactor TDD process, the second step of making the test pass means we write the simplest (but still correct) code that can possibly work that

Domain Driven Design

Domain-Driven Refactoring: Intro

Posts in this series: * Intro * Procedural Beginnings * Long Methods * Extracting Domain Services * Defactoring and Pushing Behavior Down * Encapsulating Data * Encapsulating Collections A common theme in domain-driven design are design patterns. When you start learning about DDD, you'll be presented with many code-level concepts such as: * Aggregates * Entities * Value Objects * Repositories

Life Beyond Distributed Transactions: An Apostate's Implementation - Dispatching Example

Posts in this series: * A Primer * Document Coordination * Document Example * Dispatching Example * Failures and Retries * Failure Recovery * Sagas * Relational Resources * Conclusion Sample code from this series In the last post, we looked at refactoring our documents to use messaging to communicate changes. We're still missing something, however - the dispatcher:

Life Beyond Distributed Transactions: An Apostate's Implementation - Document Example

Posts in this series: * A Primer * Document Coordination * Document Example * Dispatching Example * Failures and Retries * Failure Recovery * Sagas * Relational Resources * Conclusion Sample code from this series In the last post, I walked through the "happy path" scenario of coordinated communication/activities between multiple resources that otherwise can't participate in a

Distributed Systems

Life Beyond Distributed Transactions: An Apostate's Implementation - Document Coordination

Posts in this series: * A Primer * Document Coordination * Document Example * Dispatching Example * Failures and Retries * Failure Recovery * Sagas * Relational Resources * Conclusion Sample code from this series Quick note - I've updated this post to use the more accurate term "Document" than the less-accurate, DDD-specific term "Aggregate". In the images, it

Distributed Systems

Life Beyond Distributed Transactions: An Apostate's Implementation - A Primer

Posts in this series: * A Primer * Document Coordination * Document Example * Dispatching Example * Failures and Retries * Failure Recovery * Sagas * Relational Resources * Conclusion Sample code from this series For those working with SQL databases, working with transactions is more or less a given. The most we may need to worry about is:

Vertical Slice Architecture

Many years back, we started on a new, long term project, and to start off with, we built the architecture around an onion architecture. Within a couple of months, the cracks started to show around this style and we moved away from that architecture and towards CQRS (before it had

Distributed Systems

Dealing With Optimistic Concurrency Control Collisions

Optimistic Concurrency Control (OCC) is a well-established solution for a rather old problem - handling two (or more) concurrent writes to a single object/resource/entity without losing writes. OCC works (typically) by including a timestamp as part of the record, and during a write, we read the timestamp: 1.

Domain Driven Design

Domain Command Patterns - Handlers

In the last post, we looked at validation patterns in domain command handlers in response to a question, "Command objects should [always/never] have return values". This question makes an assumption - that we have command objects! In this post, I want to look at a few of our options

Domain Command Patterns - Validation

I don't normally like to debate domain modeling patterns (your project won't succeed or fail because of what you pick), I do still like to have a catalog of available patterns to me. And one thing that comes up often are "how should I model commands?": In general, apps I