3 ms·

I attended a few DDD meetup a few years ago, and it never quite made sense why would you engage in this kind of architecture nowadays. The room was filled with

by Fiahil 5y ago

I attended a few DDD meetup a few years ago, and it never quite made sense why would you engage in this kind of architecture nowadays. The room was filled with experienced Java developers with deep Enterprise Software(tm) knowledge. Then, I started working as an AI Software Engineer (mix of a software engineer + devops + data scientist), and it all clicked. DDD is a wonderful design pattern for anything related to Data Science, AI, ML. Why ? because 90% of your problems is retroactively making sense, organizing, sorting, filtering, aggregating all the data you got from your favorite Data Base/Lake/Wharehouse. DDD let you have a unified language, invariant definition and expectations between your existing business challenges and the analytics your are running on it. It's very good for validating assumptions accross a dataset, for example: Sales amount can never been < 0 ? Let's check that... Oh well, you forgot about returns, so now you can define them and be explicit when to include or exclude them.

adam_ellsworth 5y ago
> invariant definition What's that? I haven't encountered that terminology before.
- Fiahil 5y ago
  "Sales quantity are always > 0"; "Ticket number are unique"; "Returns are always linked to an existing ticket" You know, stuff you usually put in assert statements. Except in real life you don't have strict application of these laws in the data. So you need a way to find out what percentage of your data is "misshapen" and what to do with them. You can't necessarily filter them out, because they might reflect some business process with relevant information. You goal is to easily identify these outliers without crashing your processing (that would be stupid).
- buzzwordninja 5y ago
  Invariant: doesn't vary. Things that always are (or should be) true.
MihaiSandor 5y ago
And the most important thing is that you have clear benefits in communication using a common domain language.
- berkes 5y ago
  I need to second this. The ubiquitous language alone, is highly valuable. Even if you dislike the ideas about software architecture that DDD introduces, having a clear, broadly carried, living dictionary, helps a lot! No more EntityTreeSectionBatchBuilder, but CompanyDivisionBuilder. No more 'yea, the ActorModel is really what should have been the User, but since User has legacy in the Authentication part (which also does some authorization, it's on the backlog), we needed another model name. But also, learning about your domain, writing that down, outside (or before) patterns, frameworks, libraries start enforcing their domain, is very liberating and valuable in the long run.

by Fiahil 5y ago

adam_ellsworth 5y ago

> invariant definition What's that? I haven't encountered that terminology before.

Fiahil 5y ago
"Sales quantity are always > 0"; "Ticket number are unique"; "Returns are always linked to an existing ticket" You know, stuff you usually put in assert statements. Except in real life you don't have strict application of these laws in the data. So you need a way to find out what percentage of your data is "misshapen" and what to do with them. You can't necessarily filter them out, because they might reflect some business process with relevant information. You goal is to easily identify these outliers without crashing your processing (that would be stupid).
buzzwordninja 5y ago
Invariant: doesn't vary. Things that always are (or should be) true.

MihaiSandor 5y ago

And the most important thing is that you have clear benefits in communication using a common domain language.

berkes 5y ago
I need to second this. The ubiquitous language alone, is highly valuable. Even if you dislike the ideas about software architecture that DDD introduces, having a clear, broadly carried, living dictionary, helps a lot! No more EntityTreeSectionBatchBuilder, but CompanyDivisionBuilder. No more 'yea, the ActorModel is really what should have been the User, but since User has legacy in the Authentication part (which also does some authorization, it's on the backlog), we needed another model name. But also, learning about your domain, writing that down, outside (or before) patterns, frameworks, libraries start enforcing their domain, is very liberating and valuable in the long run.