2 ms·
> After all that, I think the concept of a ubiquitous language is excellent. Everyone should standardize on a common set of vocabulary. We even took it so far a
by Cthulhu_ 2y ago
> After all that, I think the concept of a ubiquitous language is excellent. Everyone should standardize on a common set of vocabulary. We even took it so far as to have a dictionary of our business domain terms. It's so obvious in hindsight that it seems completely foolish to do anything else.
See, while I have very limited experience actually writing code in DDD style (and at the time, because I hadn't read the book or followed any course, terms like "aggregate" were pretty alien to me), I can really see the benefit of the DDD approach to mapping out and defining a problem space or company; ubiquitous language, bounded contexts (a "customer" may be different depending on whether you ask frontline customer support vs corporate support), and just mapping out the flows and processes of how a company or part thereof are just super valuable. Because a lot of the ones I've worked for as a consultant (read: code robot for hire) seem to rely a lot on a number of key people or departments that have this knowledge in their head, while IMO it should be a central "database" of the One Truth that everything else in the company follows from, including software.
And if the processes and requirements are clear, then software will follow, whether they do DDD practices or not.
- epolanski 2y agoMe too, while I hated DDD at the beginning due to how terribly and poorly defined it is, it's really a good fit in both OOP and FP land. I have very little doubts on how to traverse and what/where to touch in a DDD application. I know where I extend the logger, and where do I add business logic without much doubt. Everything ends up well organized. I have to say I'm also lucky to never have worked with unpractical engineers fighting over exact boundaries when applying DDD something that seems to be plaguing some other users in the comments.