DEV Community

Discussion on: How To Structure Your App In a Way That Scales.

Collapse
 
brokenthorn profile image
Paul-Sebastian Manole • Edited

DDD honestly has been the best thing I've learned that helps with structuring business apps. When writing business apps, or just about any app that's more than trivial, you think in and about contexts. A domain exists within any app. There's a domain in everything. But if your app is more complex, you need to start organising it in a way that makes most sense. That's where DDD helps keep things localised, to keep them in focus when working in a certain context, because usually such apps have more than 2 or 3 contexts (or distinct features) that it needs to handle. DDD calls these bounded contexts.

Of course DDD is more than this so I recommend anyone to learn DDD if they want to get better at writing well organised, easy to maintain apps from the start. You don't have to read the blue book (there's too much stories at the beginning that can get you bored), but read a good book on applied, practical DDD, watch a few videos on Event Storming, to get a better idea about how to find bounded contexts, and soon you'll never want to structure your apps differently, whenever you start a new project.

Collapse
 
aschwin profile image
Aschwin Wesselius

True, DDD can help a lot in a sense of thinking into structured code. However, the pitfall (not only with DDD btw) is that decomposition (into structures) is most likely based on functional aspects.

Why is this a pitfall? Because it makes it prone to volatility of the business (rules). I suggest anyone to read the book Righting Software to understand more about this.

Doing decomposition right is a daunting task and few have mastered this.

Collapse
 
brokenthorn profile image
Paul-Sebastian Manole

Apps will always be prone to the volatility of the business rules. Doesn't mean it's a bad thing. It's just the way things are.

Thread Thread
 
aschwin profile image
Aschwin Wesselius • Edited

Who says it's a bad thing? I also just state that is how it is. This also means this should be taken into consideration while putting a system together if you want to be able to maintain the system later on.

If you look around hardly any system is build this way. If you look even further, this is where the systems start to fail. This means it is crucial to understand this fact.

I'm happy Juval Löwy wrote the book "Righting Software" so we can learn from his experience and hands on knowledge of decades building systems the right way. Systems build on time, on budget and with zero defects.

Thread Thread
 
brokenthorn profile image
Paul-Sebastian Manole

Cool... So is he the only one that wrote about how DDD system break down or whatever?