8 ms·
The Domain-Driven Design Paradox (2016)
- blobman 10y agoFrankly, concepts like Ubiquitous language ARE definitely a silver bullet - I've written an article on how they increase your bus factor ( http://www.michalpaszkiewicz.co.uk/blog/busfactor/ http://www.michalpaszkiewicz.co.uk/blog/busfactor/ )
- pwm 10y agoUbiquitous language only exists in mature domains. If you think of mathematics as the ultimate example of clear and precise language with rigorous definitions then most domains are on the other end of the spectrum. In these domains there are multiple names for the same concept within a department let alone the whole company. Changing that requires patience and continuous direct access to stakeholders/experts. Not impossible but I have rarely seen it work to its full potential.
- blobman 10y agoYou are absolutely right, but campaigning for a ubiquitous language in a company has far more benefits than just the application of DDD to your code. In meetings with other teams or stakeholders, we often hear or say things like "can we agree to call this thing this from now on". We then proceed to clarify exactly what is meant by the terms. It goes a long way.
- saycheese 10y agoCache of page: http://webcache.googleusercontent.com/search?q=cache:http://ouarzy.azurewebsites.net/2016/02/17/the-ddd-paradox/ http://webcache.googleusercontent.com/search?q=cache:http://...
- Dolores12 10y ago> Error 403 - This web app is stopped. Oh, 2017... We need web app to show static content.
- pavlov 10y agoTo be pedantic, I guess a program that responds to HTTP requests and just does "pipe(file, response)" would also be a "web app", even though it's serving static content...?
- nbevans 10y agoThis. We've been pushing Microsoft to add static site support to Azure Blob Storage for years but keep getting rebuffed. Apparently their official advice is to spin up a free "Web App" - as if that is in any way comparable to a truly distributed static file server like S3 / AzStorage.
- numbsafari 10y agoClearly they don't want your business. So, why not use someone like GitHub, AWS, or GCP who does?
- user5994461 10y agoUse wordpress for your content. The clouds will charge $300 when you'll go first page on HN. You don't want that.
- abdullin 10y agoI have a counterexample. My blog is hosted on AWS S3 with CloudFront CDN and costs a few dollars per month (most of that comes from Route 53). One day it appeared on the front page of HN. Total blog cost that month didn't exceed 5 USD.
- user5994461 10y agoYou are lucky to have a small audience and no media to deliver.
- wmccullough 10y agoThanks! I don't know if we hugged it to death or what. You rock.
- saycheese 10y agoPer Azure, there are 3 conditions that can cause this error to be presented: - The site has reached a billing limit and the site has been disabled. - The website has been stopped in the portal. - The Azure website has reached a resource quota limit that applies to either free or shared scale modes. SOURCE: https://blogs.msdn.microsoft.com/waws/2016/01/05/azure-web-apps-error-403-this-web-app-is-stopped/ https://blogs.msdn.microsoft.com/waws/2016/01/05/azure-web-a...
- deleted 10y ago[deleted]
- techdominator 10y agoI don't think DDD is a silver bullet; building quality software will require DDD but it will also require more. But don't get me wrong, I always been a proponent of keeping Domain concerns in The Domain layer. It makes much more things easier in the long run, beginners should be exposed to DDD very soon in the learning process, in my opinion. DDD and the principle of separation of concerns always reminds of Uncle Bob screaming "DATABASE IS DETAIL!": https://www.youtube.com/watch?v=o_TH-Y78tt4&t=42m45s https://www.youtube.com/watch?v=o_TH-Y78tt4&t=42m45s
- coconut_crab 10y ago> 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 agoI 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 agoWhat'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.
- davis 10y agoDo people still recommend Eric Evans' book on DDD? Or would Vaughn Vernon or Scott Millett be better ways to learn it as of now?
- anorwell 10y agoI have only read Eric Evans' book, but it is excellent and still very relevant.
- blobman 10y agoVernon's Implementing DDD is an excellent supplementary book to Eric Evans', but it also works well as a Stand-alone book. I generally refer to them as "the Blue Book" (Evans) and "the Red Book" (Vernon). I still haven't read the Blue Book, but I will in due course. The Red Book has given me more than enough understanding of DDD to put it into practice in the workplace.
- numbsafari 10y agoI personally found the Vernon book to be overly repetitive and actually light on real application guidance. It almost turned me off to DDD. The Evans book is the better investment by far.
- thijsvandien 10y agoWhile Millett and Tune's book is generally good, it too is very repetitive about the fundamentals.
- jgrodziski 10y agoYes I would definitely recommend Eric's book for the deep insights it contains, but it may not be the easiest to read, especially for non-native english readers as his english is quite formal. Scott Millet's book is also very good. For an introduction to DDD you can have a look at a conference video here my friend Thomas Pierrain and I made : http://videos.ncrafts.io/video/167722768 http://videos.ncrafts.io/video/167722768 (shameless plug :-))
- zapov 10y agoWhile I like DDD very much (created much tooling over last 10 years to help develop software in such a way), but if you move outside of useful implementations, you don't end up with much. Talking to domain experts, analyzing your domain... that's just a straw man arguments to sell DDD. Ubiquitous language is a good argument for DDD, but I don't see that practised a lot. There is often a noticeable disconnect between how experts talk about the system and the abstractions in the system which represent them. Also, on technical level, while there are a lot of useful things in DDD (aggregate roots, value objects, repositories, ...) there is also a cargo-cult like notion what is a good way to develop software. And when you listen to "the experts" you often get a feeling they can fake the talk, but surely don't know how to walk. My single question to see if someone is practicing DDD is: do you refactor your codebase on deeper insights? I'm yet to see someone say yes to that. Often you get excuses not to touch code which is working since refactoring large codebase is impractical/risky.
- blobman 10y agoI refactor my code fairly regularly (as specifications change). The use of TDD, DDD, CQRS and Event Sourcing gives me immense flexibility to be able to refactor a large codebase and then test it through its whole lifespan (with actual data).
- lpedrosa 10y ago> The use of TDD, DDD, CQRS and Event Sourcing gives me immense flexibility to be able to refactor a large codebase and then test it through its whole lifespan (with actual data). What is your experience in applying those principles in a team? It would be very interesting to get some insight on it.
- blobman 10y ago1. TDD is simple enough. Everyone should be doing it. 2. DDD - this usually results in plenty of healthy debates on naming conventions. Acronyms are abhorred and we try to agree with the stakeholders on the meaning of each word they use. 3. CQRS and Event Sourcing - this has required our team quite a bit more of startup time than a CRUD application would have. We have been lucky to have a very understanding Product Owner who gives us plenty of time to deal with tech debt. Although single features may have originally taken us longer (than the time it would have taken to do the same with CRUD) at the start of the project, years on this time and the complexity of refactoring or adding features has not really increased, as any functionality is contained within its bounded context. The biggest difficulty has been explaining what we are doing and why to senior management. But we haven't had any bad incidents so far, so I think they like us.
- ninjakeyboard 10y agoAgreed. Focusing on the domain is never a bad idea. The application of DDD can be insane though. If you have to learn about event sourcing and CQRS and microservices architecture, and schema evolution, and scala and Akka cluster with sharding and singletons and whatever else is employed just to be able to function, it can be very impractical to build and grow teams, let alone run the software.
- OpenDrapery 10y agoWhen the developer is the domain expert, you've achieved the singularity. /s A large percentage of the time, there is no domain expert available, or there simply is no domain expert. We've all worked at that place. You start a new job and you're left to your own devices to sink or swim. You wonder why no one can be bothered to take the time to give you the big picture. Who is the customer? Who is the user? Are they the same person? What problems are we trying to help them solve? Are we optimizing for speed, correctness, usability? How do our competitors do it? Who are our competitors? How about some backstory on this codebase? I can look through source history like I'm doing an archaelogical dig. But how about a narrative on why certain choices were made? The reason no one will take the time to answer these questions for you is that they will quickly be exposed as not having answers. The best they can do is say "I'll have to ask so and so", and then you'll never hear back. Also, there is a pervasive vibe that when you're brought on as a developer, it's not your place to ask business-y type questions. Let the people person talk to the people, and you dig ditches where we tell you to dig them. And if we ask you to fill it back in because we told you to dig in the wrong place, well then, you're here 40 hours a week and work is work right? /end rant Sorry guys, my fingers just kept typing.
- desireco42 10y agoActually this is the most pervasive problem with on-boarding. It comes from lack of understanding of role you will be performing from business side, and from the developer side, mostly tech people who were advanced to role of tech lead, different cto's and vp's have very poor management skills and are just faking it. And all of actual developers are suffering because of it.
- wpietri 10y agoI've never worked at a place without a domain expert. If the company's new, then everybody's aware that they're learning, and so they actively seek expertise. If the place is old, then I've always been able to find people who understand the domain; they've been soaking in it for years. What you're asking for is something a little different, somebody who can feed you a pre-digested analysis, one suitable for understanding/designing the code. That definitely doesn't exist. That person must be us. We understand our domain, computers. They understand their domain, business. They will never understand computers particularly well. So it's incumbent on us to lead the collaboration to create a shared domain model, a formal map of their territory. Of course, some places do try to stop us from working in the ways that are most effective, to treat us as robots. When that happens, the old Agile advice applies: either change your organization or change your organization.
- hermitdev 10y agoA bit of advice to authors: define acronyms when you first use them. DDD is defined the link text locally, on HN, but not at the site. CQRS & CRUD are also not defined. I'm familiar with CRUD, but not CQRS. DDD, lacking context, I was initially thinking the graphical front-end for gdb.
- hermitdev 10y agoTL;DR: There's too many T.L.A.'s pulled out of A.S.S.'s and sometimes, a bit of context to disambiguate is helpful.