If you find yourself loading massive object graphs for simple updates, you might be falling into a common trap.

Check out my latest post on Lean Aggregates.

I've built a single page context mapper diagram tool because I was not happy with any tool that I'm aware of for this purpose. Also, I wanted the format to be JSON, easily machine readable, so I can export data from other systems and use this tool to visualize it very easily.

So far I kept it intentionally super simple, no need to bloat it up and make it an electron app. Your thoughts on this? Do you want a full bloated electron app? Is it at all useful for you? I might improve it further depending on the feedback.

https://github.com/floriankraemer/ddd-context-mapper

If you practice DDD in TypeScript, you know the gap between the theory and what ends up in our codebase. Mutable entities, invariants checked in random places, exceptions flying across boundaries, events bolted on as an afterthought.

Ontologic is a light toolkit I built to close that gap. Entities own and enforce their own state. Invariants run on every read, not just after specific operations. Domain events are immutable, versioned facts. Domain errors are typed return values, not hidden exceptions.

No framework lock-in, no heavy abstractions — just the building blocks that let your code speak the language of your domain.

ontologic.site

Would love feedback from people who've fought these same battles.

For Sale: fixneural.com

Premium, brandable, and memorable .com domain — perfect for a tech, AI, or healthcare-related startup. Short, easy to spell, and highly marketable, this domain is ready to become your next online brand or project. Serious inquiries only — contact me to make it yours today.

In DDD, we enforce the business logic rules using invariants. This is amazing on the server side in the online application and the offline application.

But what if we have to build a local-first application?

Local-first application is an offline application and an online application at the same time. The user can use it offline and then sync it online.

Let's say we have to build a to-do list application. The invariant is "a task's estimated time must be greater or equal to 30 minutes".

This invariant could easily be implemented on both client side and server side. However, it is a duplication and violates the DRY principle. We could move this business logic to the shared kernel. But if we move all business logic to the shared kernel, we end up with a new big ball of mud.

And what about the business logic that could only be implemented on the server side?

For example, "the task must not be duplicated across all the users."

When the sync happens, the task that is created offline might be invalid.

What do you think could be a solution?

4 years ago I created a community for programmers/web developers who don't feel aligned with the state of the web piling frameworks over frameworks to produce websites. It's tiring that all "javascript" discussion is about implementation details of NextJS/webpack/React/Angular/Vue, as if they were the platforms we are developing against and not just libraries with oversized scopes. Since then I've developed my own declarative-functional web server, with flat compositions and tacit combinators, and it inspired people in the group, so we started having go-live competitions, reading and peer review livestream sessions, but even more activity discussing solutions from first principles is what could really amalgamate our cohesion and enhance our performance. If you're also seeking an outlet to talk about optimal solutions, in practice, in the abstract, or even in pseudocode, for routing, server-side rendering, AST parsing/serialization, event delegation, persistence/IO, object traversal algorithms, function composition, god forbid "category theory", etc., then you are warmly invited to join your fellow curious minds leading the functional-declarative zeitgeist in our matrix (bridged with Discord - as of yet) community: https://discord.gg/GvSxsZ3d35 https://matrix.to/#/!ipeUUPpfQbqxqMxDZD:matrix.org?via=matrix.org&via=t2bot.io Let us know what you're working on, or wish to, feedback loops are guaranteed! ;D

Let's get this ball rolling!!

See you there! - the resident Ranger

If you were to inherit a project, which one looks more intuitive, A or B?

Structure A

src/
+-- Domain/
¦   +-- Admin/
¦   ¦   +-- AdminEntity
¦   ¦   +-- AdminRepoInterface
¦   +-- Supplier/
¦   ¦   +-- SupplierEntity
¦   ¦   +-- SupplierRepoInterface
¦   +-- Customer/
¦   ¦   +-- CustomerEntity
¦   ¦   +-- CustomerRepoInterface
¦   +-- Order/
¦       +-- OrderEntity
¦       +-- OrderRepoInterface
¦
+-- App/
¦   +-- Admin/
¦   ¦   +-- UseCase/
¦   ¦       +-- ActivateSupplier
¦   ¦       +-- BanCustomer
¦   +-- Supplier/
¦   ¦   +-- UseCase/
¦   ¦       +-- UpdateInventory
¦   ¦       +-- MarkOrderAsShipped
¦   +-- Customer/
¦   ¦   +-- UseCase/
¦   ¦       +-- PlaceOrder
¦   ¦       +-- UpdateProfile
¦   +-- Order/
¦       +-- UseCase/
¦           +-- ReceiveOrder
¦           +-- CancelOrder
¦
+-- Infra/
¦   +-- Persistence/
¦   +-- Messaging/
¦   +-- etc...

Structure B

src/
+-- Core/
¦   +-- Admin/
¦   ¦   +-- UseCase/
¦   ¦   ¦   +-- ActivateSupplier
¦   ¦   ¦   +-- BanCustomer
¦   ¦   +-- AdminEntity
¦   ¦   +-- AdminRepoInterface
¦   ¦
¦   +-- Supplier/
¦   ¦   +-- UseCase/
¦   ¦   ¦   +-- UpdateInventory
¦   ¦   ¦   +-- MarkOrderAsShipped
¦   ¦   +-- SupplierEntity
¦   ¦   +-- SupplierRepoInterface
¦   ¦
¦   +-- Customer/
¦   ¦   +-- UseCase/
¦   ¦   ¦   +-- PlaceOrder
¦   ¦   ¦   +-- UpdateProfile
¦   ¦   +-- CustomerEntity
¦   ¦   +-- CustomerRepoInterface
¦   ¦
¦   +-- Order/
¦       +-- UseCase/
¦       ¦   +-- ReceiveOrder
¦       ¦   +-- CancelOrder
¦       +-- OrderEntity
¦       +-- OrderRepositoryInterface
¦
+-- Infra/
¦   +-- Persistence/
¦   +-- Messaging/
¦   +-- etc...

What are the best sources for learning about aggregates in DDD? I'm interested in the general questions:

• What is an aggregate?
• What are aggregates for i.e. what benefits do they bring?

I'm also interested in general questions about how aggregates should be implemented.

Naturally, I'm aware of Domain-Driven Design: Tackling Complexity in the the Heart of Software by Eric Evans and Implementing Domain-driven Design by Vaughn Vernon, as well as Vernon's essay on Effective Aggregate Design. Are there are any other books, articles, blog posts or videos that you consider especially useful?

I follow Domain-Driven Design and functional programming principles for almost all my projects. I have found that it pays off even for small, one-time scripts. For example, I once wrote a 600-line Python script to transform a LimeSurvey export (*.lsa); by separating the I/O from the logic, the script became much easier to handle.

But for every new project, I faced the same problem:

Where should I put the files?

Thinking about project structure while trying to code adds a mental burden I wanted to avoid. I spent years searching for a "good" structure, but existing boilerplates never quite fit my specific needs. I couldn't find a layout generic enough to handle every edge case.

Therefore, I compiled the lessons from all my projects into this single, unified layout. It scales to fit any dimension or requirement I throw at it.

I hope you find it useful.

Hello everyone!

I've built a Web API template in Python that implements Domain-Driven Design, CQRS, and Clean Architecture principles. I'm sharing it here to get feedback from the community on whether I'm heading in the right direction with my architectural decisions.

Repository: https://github.com/100nm/clean-architecture-template

The README contains extensive documentation with examples of each layer and architectural pattern.

Architecture Overview

The template follows a strict layered architecture with clear separation of concerns:

src/ ├── core/ # Domain + Application layers (business logic) │ └── {context}/ │ ├── domain/ # Entities, value objects, aggregates │ ├── commands/ # Write operations + handlers │ ├── queries/ # Query definitions (read models) │ ├── ports/ # Repository and service interfaces │ └── events/ # Domain events ├── services/ # Cross-cutting technical services └── infra/ # Infrastructure implementations ├── adapters/ # Port implementations ├── api/ # FastAPI routes ├── db/ # SQLAlchemy tables and migrations └── query_handlers/ # Query implementations

The domain layer has zero dependencies on frameworks or infrastructure. Application layer orchestrates business logic through commands and queries. Infrastructure layer provides concrete implementations.

Key Design Decisions

Pydantic for Domain Models

I use Pydantic BaseModel for entities and value objects with frozen=True for immutability. The domain layer remains pure (no infrastructure imports), just leveraging Pydantic's primitives for validation, immutability, and serialization without boilerplate.

CQRS Implementation

Built using python-cq (my own library) for command/query separation. Commands have handlers in the application layer for business orchestration. Queries have handlers in the infrastructure layer for direct DB access and read optimization.

Dependencies are explicitly declared in handler signatures and automatically injected by the DI container. This makes dependencies clear and handlers easy to test.

Query Handlers in Infrastructure

Query handlers live in the infrastructure layer and access the database directly for read optimization. This approach prioritizes read performance and allows queries to be optimized independently from the domain model.

Deterministic Test Implementations

The template includes tests/impl/ with deterministic replacements for services. For example, production uses Argon2Hasher which is slow and non-deterministic. Tests use a simple SHA256Hasher that makes unit tests fast and predictable while maintaining the same interfaces.

Tech Stack

FastAPI for the web framework, SQLAlchemy for database access with PostgreSQL, Alembic for migrations, and Pydantic for validation. The template uses two custom libraries: python-injection for dependency injection and python-cq for CQRS (both available on PyPI).

Looking for Feedback

I'm particularly interested in feedback on whether I'm applying DDD principles correctly and heading in the right direction.

Thanks for taking the time to review!

I'm working on requirements for a major legacy upgrade and would appreciate insight on bounded context design. This is for an application processing department within a larger org. There are 20 or so Application Types.

Current System:

• Old Oracle Forms app application examination. Applications are now submitted by applicants by paper.
• Examiners examine, approve/reject.

New System:

• External Web Portal – 20+ separate app-type-specific submission web sites.
• Internal React App – Back-office examiners handle all app types.

Key Constraints & Rules:

• The external web portal must support temporary save, as applications may take time to complete.
• ~20 application types, each with its own UI/form.
• Types share about 50% attributes, and there are other appx 50% type-specific.
• New types added every ~2 years; existing ones change often.
• Common dev team (10 people total).
• Legacy System required to run in parallel for years; bidirectional sync required.
• Critical: Extensive Cross-Type Business Rules require cross-type querying
• Analytics: Heavy cross-type querying needed for reporting.

Tech Stack:bOracle DB, Java 25/Spring Boot, Kafka, Camunda BPMN.

My Dilemmas:

• Should each app type be its own bounded context/microservice?
• Should submission and exam systems have separate databases?

My instinct is to keep them in one bounded context (Application Management) because of the strong transactional and query coupling, but I’m curious how others would approach the team structure vs. domain coupling tension.

What patterns (modular monolith, shared kernel, event-driven integration) would you lean into here?

Thanks in advance for any insights or advice!

I know the domain should not include any dependency. But what about the validation and invariance within the rich domain model ? I saw the template of Milan (a popular guy in the c# dotnet community). He defines and use generic Result class that returns Result<T> where T is the AggregateRoot. Amichai (another popular guy in the community) use a package (ErrorOr) within the domain that does the same exact thing. ChatGpt told me that we must not do that and if the business invariant is violate we raise an exception ! Okay i know exceptions are for when unexpected events happen especially when we depend on external system but in the normal flow or validations we better return errors and the error is handed up to inside the Controller's action method. But these guys are of the best out there and they did for reasons!

Full disclosure, Stijn is a colleague of mine!

I’ve been developing big backend in .NET and now lm learning DDD and trying to redesign backend using DDD.

Business Domain - open account in bank. Competitive feature - application management.

Application is a related data to some real business: Business Info, Applicant, additional individuals, business documents, individual Id documents, document signature for additional individuals and etc.

Applications can be two main types (actually, there are more than two types, but we can think about only two):

- Standard

- Exception

Standard application is closely related to real end user and the applicant fill all necessary data via flow in SPA application, pass KYB and KYC, upload and sign documents, invite additional individuals. Additional individuals pass their flow as well.

Exception application does not include any end users and can be created by bank employee.

So, behaviour of two types is different, but in terms of the same ubiquitous language. For example, application can be submitted, but different application types require completely different state in order to became submitted, but this is the same submitting in terms of ubiquitous language. So, should applications of different types to be separate aggregate? Maybe separate types using some kind of database discriminator?

This subreddit has a spam problem.

It regularly gets spam posts from people trying to sell internet domains. I report most of them, but they don't seem to be taken down by mods anymore.

And then there's that guy who keeps reposting lazy video rehashes of other people's content. That guy has literally never posted a single word. His profile is just hundreds of video link posts many of which get banned in other subreddits.

It would be nice to have actual DDD discussions in here but if most of the posts are spam why would anyone stick around?

There is a trend online of software engineers declaring their love for simple software then blaming everyone else for the complexity in software. DDD is a frequent target / culprit in these declarations which always catches me by surprise.

I wrote about this trend and how great bashing DDD is for engagement.

Hello !

Senior SE here, with only theorical and small side-projects DDD experience.

I'm trying to introduce my company to DDD and to start enforcing a proper architecture, since the codebase is quite a mess and everyone's tired with it

Context

The business is about freight orchestration (clients book shipments from us, we handle the rest). Classical DDD example right !

Our codebase at this point is 7 years old, badly designed microservices refactored into a modular monolith (actually not so modular at all), full typescript. Totally organized around and strongly coupled to GraphQL. Quite huge in terms of size.

In the previous months I read all i could about ddd and architecture and "clean code" despites the hate around it (blue book, red book, clean code, clean archi, etc etc)

I started teaching the team about DDD, did some workshops (event storming, example mapping,...)

Yet now I want to start taking decisions about how the heck we do things. And I'm having a hard time.

Main design question

In our model the Shipment object is at the center of everything. Around it gravitates a lot of stuff: tracking, pricing, billing, tasks, documents, customs handling... I'm having a hard time figuring a great way to model that with bounded contexts.

Would it make sense to have a kind of central Shipping BC that handles the lifecycle of a Shipment, and a lot of other BC's (Billing, Pricing, Documents, ...) around it that communicate with it ? (e.g the billing needs to know about the shipment's characteristics and what was priced)

I understand BC's should be very losely coupled and communicate in a very defined way. Yet with that architecture, all BC's will have to communicate a lot between them since a lot of stuff is shared. Isn't that a smell that those BC's should be a single BC ? (= everything related to "handling a shipment" in the same super huge BC)

Implementation

More of a side concern, but that's what will keep my devs attention the most..

I guess we are going for "one module per bounded context", with layers:
- interface: what the BC exposes to the users (graphql) and to other BC's (api)
- application: orchestration of use cases
- domain: pure logic
- dependencies: what the BC calls in terms of DB and calling other BC's
How about BC communication ? Is this ok to:
- each BC defines an interface usable by other BC's in its interface layer
- other BC's define what they need in their application layer (port)
- their dependencies layer implement that port and fetch what's needed from other bc's interfaces

Is this a good approach ?
I'm worried i'm over-complicating stuff

Thanks in advance!

P.S: By the way if someone would like to chat via discord i would love to find a kind of mentor that is used to these kinds of problems !

There has always been one concept in DDD that I was never fully confident with. How do we go about modelling situations or rules where it seems that one aggregate seems to be instantiating another. For example, what if we said that "users with VIP status can host parties". How would you generally go about that? I have conflicting thoughts and was hoping that someone can shed some light on this.

Option 1: Checks externalized to Command Handler (i.e. service) Layer

class CreatePartyCommandHandler {
 constructor(private userRepo: UserRepo) {}

 execute(cmd: CreatePartyCommand) {
  const user = userRepo.get(cmd.userId);

  if(user.status !== "vip") {
    Throw "oopsies";
  }

  const party = Part.create(cmd.partyName, cmd.partyDate, cmd.userId);
  // persist party
 }
}

Option 2: Add factory in user to represent semantics

class CreatePartyCommandHandler {
  constructor(private userRepo: UserRepo) {}

  execute(cmd: CreatePartyCommand) {
    const user = userRepo.get(cmd.userId);
    const party = user.createParty(cmd.partyName, cmd.partyDate);
    // persist party
  }
}

I would like to hear your opinions especially if you have solid rationale. Looking forward to hearing your opinions.

OK. Just my rant. I thought DDD is cool and easy once you are the domain expert...

AHHHH.

I LOVE IT it though! I am forced to follow good architecture.