Hacker News new | past | comments | ask | show | jobs | submit login
The Domain-Driven Design Paradox (2016) (ouarzy.azurewebsites.net)
108 points by fagnerbrack on Jan 30, 2017 | hide | past | favorite | 53 comments

When 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.

I'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.

> either change your organization or change your organization

Two different but related meanings coming from two valid parses of the same string, nice!

Actually 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.

> When the developer is the domain expert, you've achieved the singularity. /s

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

Funny that you mention that the report writer becomes the person closest to understanding the business.

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).

I ran into a developer that was happy and proud that no report writer could generate a report of a transaction because he did all the calculation on the fly and couldn't be bothered to store some critical data in the database. He basically said that the report writer would have to duplicate the program logic in the stored procedure returning the report data. He was honestly happy and didn't think he needed to take the time to fix it.

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.

This is why I wish developers would leave test packs with Gherkin specifications behind. The code ends up being the only source of truth without them, and the archaeology has to begin.

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".

> 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..

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.

Just to reinforce what you are saying, there were people doing this even in ancient Greece, see Plato's Gorgias.


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.

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.

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.

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.

This is true to a large extent. But what about a framework like apache Isis(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 ?

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) 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.

Per 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-a...

> Error 403 - This web app is stopped.

Oh, 2017... We need web app to show static content.

To 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...?

This. 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.

The "Web App" is the thing that turns a request in to a response. Even if that is as simple as reading a static file and returning it unmodified as the body of the response.

"Web App" is just their branding. It's just a web server that can stop/start/scale automatically as opposed to being 'always-on'.

Clearly they don't want your business. So, why not use someone like GitHub, AWS, or GCP who does?

Use wordpress for your content.

The clouds will charge $300 when you'll go first page on HN. You don't want that.

I 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.

You are lucky to have a small audience and no media to deliver.

Thanks! I don't know if we hugged it to death or what. You rock.

While 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.

I 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).

> 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.

1. 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.

Do you do full-blown event sourcing or apply it to specific areas only? If the latter, how do you decide which? How do you deal with performance? Specialized database (e.g. Event Store) or not?

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.

We have full-blown event sourcing for pretty much everything. The performance on the read side is great (obviously). We have an Event Store and we rebuild the Domain for every new command, so it isn't particularly fast, but we have a situation where commands are only issued a few times every year by a single person, whereas there are millions of reads every day (hence justifying CQRS as a solution). We have a mixed solution around replaying events though, largely around the issues we have with file uploads. Every file upload triggers multiple events (uploaded, processed etc) and we have different solutions for different files. Small files we store in the events as a blob, whereas big file events upload the data to a projection store and will not be replayed, so we don't have the issue of having to keep the original files forever as well as the database. I should probably write a blog post about the project at some point, but I'd like to investigate with my bosses as to how much I can actually reveal about the domain (because it would make the read so much more interesting if I could say everything).

> My single question to see if someone is practicing DDD is: do you refactor your codebase on deeper insights?

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.

Well thats kind of to the point. DDD is all about investing into your core domain since that gives you a business advantage.

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.

> 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.

> My solution to that problem is to write software with tools which make refactoring cheap and it's kind of working for me.

Relevant link posted a couple of days ago, to optimize for deletion rather than refactoring: https://vimeo.com/108441214.

Frankly, 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/ )

Ubiquitous 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.

You 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.

I 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

Do people still recommend Eric Evans' book on DDD? Or would Vaughn Vernon or Scott Millett be better ways to learn it as of now?

I have only read Eric Evans' book, but it is excellent and still very relevant.

Yes 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 (shameless plug :-))

I 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.

While Millett and Tune's book is generally good, it too is very repetitive about the fundamentals.

Vernon'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.

A 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.

TL;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.

Agreed. 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.

All those things that you mentioned are just implementation details that some people use with DDD, you can do DDD with assembly if you wanted to.

Or plain Java or C#, more likely :)

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact