Looking Feedback: Split up monolith in DDD

I'm re-reading "Domain-Driven Design" right now. My gut says that splitting things up into modules makes a ton of sense. I'm not sure if I would carve out any bounded contexts, at this point. My take is that bounded contexts really excel when there would be naming clashes in the ubiquitous language. They are, probably, also useful if you have a large team and a team could own a bounded context, but I rarely work with teams of that size.

On a side note, there's nothing inherently wrong about a monolith. I'd wager that for the majority of applications, it's the correct architecture. You can have a DDD monolith without any problems. I see that several of the other comments echo this sentiment.

What?

DDD is just a way to understand and contextualize what you're building. It's not an application architecture.

You can use DDD to design monoliths or microservices or anything else.

I'd agree with the below comment that microservices are more of an organizational pattern than a technical one.

If it's just you, I'd suggest you stick with a monolith but use your DDD skills to define the modular boundaries in your code. Don't share code across those boundaries, just define interfaces for them to use to communicate, ideally in an async way (like messages). Modularize your data, too, and try not to cross those boundaries in queries.

I would initially keep the order module coarse-grained, it obviously depends on what knowledge you've already distilled but if you are incrementally partitioning that's what I'd do.
Also, a comment on one of your comments below, not necessarily a microservice entails a bounded context, e.g. you could easily have a microservice which implements a transaction script. If you give more info, I'll be happy to provide more feedback.

No, under no circumstances should you be going micro services, as it will do nothing but bring you pain. Micro services are a concept turned into fad by incompetent developers who want to make themselves sound cutting edge to land contracts, but aren't going to help your business any, because they don't actually know what they're doing.

The concept of micro services was designed for large organizations such as Netflix, and not for one-man shops such as yourself. The whole concept is to modularize a large code base to make manageability easier across TEAMS of developers. So unless you have a minimum of 20 developers working on this project, and a need to split them into teams so they can focus on their portion of the system, then micro services are of no use to you, and will only lead to complicate your life with unnecessary problems.

I can't give you a solid answer to your question, as you didn't provide a database schema at all. What you need is to either, learn better database design, or contract out to a qualified developer who knows how to write a clean and efficient database schema.

First, I would say a monolith has to have customers, revenue, and be business critical. If you don't have customers or only have a few, how did you get to be a monolith? Second, I sort of feel, without having had to spit up a monolith, that keeping a monolith running is just throwing good money after bad and creating ever increasing technical debt that eventually you'll have to address.

I personally am a huge fan of microservices. The nice thing about them are that you can do a slow transition away from the monolith. You can replicate a small piece as a microservice, and slowly modify the monolith to point to the microservice. Once everything that uses that functionality is pointing to the microservice you can cut the old code out of the monolith (or leave it there if you're lazy). Then move into the next piece and so on. Eventually you have a distributed, microservice application without ever disrupting your users and without them seeing any changes.
The downside to that, slow, approach is that while you're replicating functionality and spitting things into microservices there is no features l development and very little bit fixes.

I don't think I'm really answering your question though. I think the bottom line is, is there any good reason to keep the monolith going? There's a reason monoliths are considered an anti-pattern these days and that's because they're a single point and hard to debug, support, scale, etc.

Hope that helps,