6 ms·

> Even on the implementation side of a project, there is a lot from DDD that is always usefull. It’s not always about CRUD or CQRS and Event Sourcing. But it’s

> Even on the implementation side of a project, there is a lot from DDD that is always usefull. It’s not always about CRUD or CQRS and Event Sourcing. But it’s always about naming the methods, classes, interfaces and modules according to the domain language, the Ubiquitous Language. This is DDD. > If I encourage collaboration between technical and domain experts and work iteratively to refine a conceptual model, I can claim I’m doing DDD. This. I am tired of the so-called 'DDD-experts' trying to convince us that you must use X framework with Y techniques to 'properly' implement DDD. In the eyes of some managers I know DDD is something mysterious, something that requires expert consultants to do and if we copy paste their design we will be doing 'DDD'. That explains why in my company each team has their own understanding of 'DDD'. To me, the Ubiquitous Language is the essence of DDD. As long as I name my class/method/function/variable accordingly then I am doing DDD. And we try to make it so that the Domain Experts can read our code and say its business logic is correct or not, even if they don't know anything about programming at all. To do that we can use whatever tools/languages we want, OOP, FP, Free Applicative, DSL etc.. It's the Domain that matters in Domain Driven Design, not the framework or languages or even design patterns. EDIT: Fixing formatting again..

vojant 10y ago
I fully agree, Ubiquitous Language is the key part of DDD. As long developers and business people understand processes and speak the same language you can achieve DDD using any patterns/languages/technologies. In DDD what I find the most challenging are changes and context: e.g. in typical sass application marketing team speaks about customer that comes from PCP, but from sales perspective customer is the only company setup through CRM system. Same word but often processes are completely different (post-pay, pre-pay etc). Sadly, I never work in a team that implemented fully DDD - mostly because it was too hard to engage all departments to think about processes - technology behind that was the easy part.
- arthurjj 10y ago
  What's crazy is Ubiquitous language isn't even that hard to start doing. It starts with a common glossary. I like to use an internal wiki, but that's just me. The harder part is getting people to use the language and not misuse the terms. Saying "You're saying you need a Foo, but it sounds like it's a Foo with an added Bar. Let's call it a FooBar to be clear" requires some effort to start doing.
  - ebiester 10y ago
    It depends on how big of a team you are. It turns out that some of the most common terminology ends up being the most contentious. A Customer can be a different entity to sales, support, fulfillment, and finance. As a small informal project, it has value, but madness also lies down that path.
blobman 10y ago
I absolutely agree. CQRS and Event Sourcing only make sense in some circumstances. I have heard stories of companies deciding to use them and only afterwards deciding which project to apply them to. For me, Ubiquitous Language and separation of Bounded Contexts are the primary concepts that can and should be applied everywhere.
blowski 10y ago
Everybody seems to agree that when your engineers understand the domain they are working on, they build better solutions. There is always some snake-oil salesman suggesting your engineers either don't need to understand the domain, or there's a shortcut by which they can learn it. There isn't. And every generation seems to rediscover that truth and give it a different label.
- hashhash 10y ago
  Just to reinforce what you are saying, there were people doing this even in ancient Greece, see Plato's Gorgias. http://www.gutenberg.org/ebooks/1672 http://www.gutenberg.org/ebooks/1672
petra 10y ago
This is true to a large extent. But what about a framework like apache Isis(https://isis.apache.org https://isis.apache.org), that generate the UI(and lots of other stuff) for you(but you can change it later), and claims to let you focus on domain at first, while having a running application to test with users. Or even just as a prototyping tool . Isn't it useful in theory ? or in practice? is there someone with experience with that framework here ?
- danhaywood 10y ago
  Yes, it's useful both in theory and practice. Mind you, I would say that: full disclosure: I'm a committer on the Apache Isis framework. But over the last 5 years the framework has been developed based on the needs of real-world apps that I'm fully involved in building; we then factor out stuff as need be to develop the framework. I'm always amazed at the abstraction level pretty much all the other frameworks out there... just so much hacking around with technical stuff rather than focusing on the domain. The Apache Isis framework pretty much forces the dev to work only in terms of the domain. But judge for yourself: Estatio (http://github.com/estatio/estatio http://github.com/estatio/estatio) is the real-world app (for invoicing) that we work on; there are also technical addons (http://isisaddons.org http://isisaddons.org) and generic subdomain modules (http://catalog.incode.org http://catalog.incode.org) which we've also factored out.

vojant 10y ago

I fully agree, Ubiquitous Language is the key part of DDD. As long developers and business people understand processes and speak the same language you can achieve DDD using any patterns/languages/technologies. In DDD what I find the most challenging are changes and context: e.g. in typical sass application marketing team speaks about customer that comes from PCP, but from sales perspective customer is the only company setup through CRM system. Same word but often processes are completely different (post-pay, pre-pay etc). Sadly, I never work in a team that implemented fully DDD - mostly because it was too hard to engage all departments to think about processes - technology behind that was the easy part.

arthurjj 10y ago
What's crazy is Ubiquitous language isn't even that hard to start doing. It starts with a common glossary. I like to use an internal wiki, but that's just me. The harder part is getting people to use the language and not misuse the terms. Saying "You're saying you need a Foo, but it sounds like it's a Foo with an added Bar. Let's call it a FooBar to be clear" requires some effort to start doing.
- ebiester 10y ago
  It depends on how big of a team you are. It turns out that some of the most common terminology ends up being the most contentious. A Customer can be a different entity to sales, support, fulfillment, and finance. As a small informal project, it has value, but madness also lies down that path.

blobman 10y ago

I absolutely agree. CQRS and Event Sourcing only make sense in some circumstances. I have heard stories of companies deciding to use them and only afterwards deciding which project to apply them to. For me, Ubiquitous Language and separation of Bounded Contexts are the primary concepts that can and should be applied everywhere.

blowski 10y ago

Everybody seems to agree that when your engineers understand the domain they are working on, they build better solutions. There is always some snake-oil salesman suggesting your engineers either don't need to understand the domain, or there's a shortcut by which they can learn it. There isn't. And every generation seems to rediscover that truth and give it a different label.

hashhash 10y ago
Just to reinforce what you are saying, there were people doing this even in ancient Greece, see Plato's Gorgias. http://www.gutenberg.org/ebooks/1672 http://www.gutenberg.org/ebooks/1672

petra 10y ago

This is true to a large extent. But what about a framework like apache Isis(https://isis.apache.org https://isis.apache.org), that generate the UI(and lots of other stuff) for you(but you can change it later), and claims to let you focus on domain at first, while having a running application to test with users. Or even just as a prototyping tool . Isn't it useful in theory ? or in practice? is there someone with experience with that framework here ?

danhaywood 10y ago
Yes, it's useful both in theory and practice. Mind you, I would say that: full disclosure: I'm a committer on the Apache Isis framework. But over the last 5 years the framework has been developed based on the needs of real-world apps that I'm fully involved in building; we then factor out stuff as need be to develop the framework. I'm always amazed at the abstraction level pretty much all the other frameworks out there... just so much hacking around with technical stuff rather than focusing on the domain. The Apache Isis framework pretty much forces the dev to work only in terms of the domain. But judge for yourself: Estatio (http://github.com/estatio/estatio http://github.com/estatio/estatio) is the real-world app (for invoicing) that we work on; there are also technical addons (http://isisaddons.org http://isisaddons.org) and generic subdomain modules (http://catalog.incode.org http://catalog.incode.org) which we've also factored out.