The Domain-Driven Design Paradox (2016)
ouarzy.azurewebsites.net
ouarzy.azurewebsites.net
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.
And all of actual developers are suffering because of it.
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.
Two different but related meanings coming from two valid parses of the same string, nice!
agreed with /s but...
If your report wr... excuse me... business intelligence developer doesn't become a domain expert, then you are going to have some serious problems down the road.
I've seen many developer in enterprise get asked pure business questions because they have to think about them all day long to do their jobs. Its really a strange thing about our profession because in order to program the process and take into account the edge cases you really need to be an expert at the process. Some companies lose their damn mind when a developer knows more about their business than the employee who does the process.
I've often found the most trouble from companies with managers that repeat the mantra: "we are not an IT company". That's basically the signal that you will never be acknowledged for your business knowledge.
> Sorry guys, my fingers just kept typing.
long form is alway good
In my experience, the report writer many times is the developer on the team who drew the short straw. So you get this weird effect where the best way to learn the domain is to end up with the least desirable project work (from a dev perspective).
The report was a customer bill, no report, no money.
Yeah, I get any project has tiers, but I have a special hatred for developers who dump on report writers or testers. The developers fancy achievement don't mean a damn thing unless we can get data out of it including billing.
Sadly, a lot of the trouble results from a single rule: if a developer cares about the state of a single item when making decisions, be advised that some report writer is going to have to write a report that shows all of the items in the system with that state.
If developers could just record what they wanted to achieve alongside how they achieved it my life would be much easier. I'm not even asking for the "why".
> 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..
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.
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.
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.
There isn't. And every generation seems to rediscover that truth and give it a different label.
Isn't it useful in theory ? or in practice? is there someone with experience with that framework here ?
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) is the real-world app (for invoicing) that we work on; there are also technical addons (http://isisaddons.org) and generic subdomain modules (http://catalog.incode.org) which we've also factored out.
Oh, 2017... We need web app to show static content.
The clouds will charge $300 when you'll go first page on HN. You don't want that.
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.
"Web App" is just their branding. It's just a web server that can stop/start/scale automatically as opposed to being 'always-on'.
- 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-a...
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.
What is your experience in applying those principles in a team? It would be very interesting to get some insight on it.
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.
Real life success stories about ES are rare, so I'd love to get more insight in the anatomy of the solution (way beyond these few questions). Blog post request, I guess.
I've been wanting to do this for a long time, I've devoted a lot of thought to working out when and how to perform these refactorings. But the reality is, business concerns drive the development of software, not the other way around.
The big reason why refactoring is needed is technical debt, not because the vision of the project changes. You have to get the code clean and well-designed before you'll be able to easily have insights about it. It's all a team can do to chip away at the debt slowly over time barring a bunch of resources devoted to a big cleanup.
In order to make insight-driven refactoring work, you first need to finish cleaning up your debt. Otherwise whenever you try to get started, the debt will get in your way and you'll start yak-shaving until another feature request or bug pops up.
Debt cleanup never gets finished, so refactoring on the basis of insight never gets done either.
In reality domain experts are not available (if existant at all). You implement features in shortest path possible and most of the time never really refactor. Gap between domain and implementation widens... and if you are lucky at one point decide on rewrite which only works if your devs became domain experts themselves.
My solution to that problem is to write software with tools which make refactoring cheap and it's kind of working for me.
That. This is how much of a silver bullet as we have had since Brooks wrote his book... Except that it is older, was just kind of forgotten by that time.
Relevant link posted a couple of days ago, to optimize for deletion rather than refactoring: https://vimeo.com/108441214.
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
The Evans book is the better investment by far.