Implementing Domain-Driven Design – In JavaScript

Finally, JavaScript

So, in part 1 we built the original implementation. Now let’s start porting!

There’s a git repository with the “final” solution and all the intermediate steps available as branches here. You’ll see me say git checkout step1 and so forth at many places throughout this blog series – following along is all the fun!

username$ git clone https://github.com/davidfaulkner12/iddd_js.git

I’m limiting my scope here to running the same tests against the new version of the system, and making them work. Of course, this assumes that these tests do exist. Let’s dig into the Java to find them if they do!

Looking at the build.gradle file, there’s nothing obviously an “integration test” in there, which is disappointing, but it does make our life easier.[^footnote1] For sanity’s sake, let’s constrain our view to iddd_identityacce...

Implementing Domain-Driven Design – In JavaScript

What?

In this blog series, I will be porting the Identity Access domain sample from Vaughn Vernon’s amazing book Implementing Domain-Driven Design to a node.js application.

Why am I doing this? Cultural arrogance! Java is evil and JavaScript is the best!

OK, no not really. I cut my teeth on the late 20th century wave of programming languages – my first real programming was in Perl, and I played with Perl and Python for almost all of the work where I had a choice, only working with C++ (the language of my CS program) with reluctance. However, my career started and stayed in Java land, and specifically, the Java EE world of big containers, enterprise service buses, business process management software packages, and so on.

Of course, writing enterprise web apps always involved lots of JavaScript, and when I look back at writing a SPA...

Real Advice for Distributed Projects

What makes this advice “real”?

A lot has been written about how best to run a distributed software development project, and a lot continues to be written, because it’s hard, and people keep getting it wrong. Building software is one of the hardest things that we do. As anyone who’s ever had a conference call knows, communication between multiple people that aren’t around a table is also really hard. So, take one of the hardest things that people do and make it even harder by introducing cultural barriers, time zone issues, and time-delayed audio where half the time that people are talking, it’s on mute? A perfect recipe for disaster.

Distributed projects aren’t going away, and it’s part of the job to be able to run them effectively. I feel strongly that the nature of distributed projects is different from those that are done by co-located team...