Primary Menu

Modeling Domain Entities with Universal JavaScript

Entities are the crown jewels of any application. All of those thousands of lines of client and server code have but one purpose: To persist, present, and allow the user to manipulate instances of domain model entities.

Give your entities the respect they deserve. Once you’ve worked out what they are for your domain, building and testing them thoroughly should be your next goal.

Spoiler alert: There is no One True Way to implement your entities.

There are a number of takes out there on how to represent an application’s domain model in JavaScript. Most come from other languages like Java, since JavaScript, while maturing more every year, is still relatively late to the enterprise-level application architecture party.

Much of JavaScript’s history has been strictly client-side. In those days, there was rarely a need to be more elaborate than creating an Object with { and } and setting some properties on it. But client architecture has grown more complex, and latter-day approaches tend to resemble either EJB Entities, or the Value Object pattern.If you’re interested, here is a good article on the distinctions between the two.

If you’ve seen all the other approaches and just want to dive into a simple implementation that will work on Node or in the browser, is framework-agnostic and dependency-free, then by all means, take a gander at the js-entity-modeling GitHub repo. Otherwise, read on to see what my driving concerns were.

Avoiding Duplication of Effort

The most elaborate modeling and validation of the application’s domain entities usually takes place on the server, to ensure database integrity. But validation should always be done on the client too, so as to avoid unnecessary conversations with the server. In the past it was just a given that in-browser validation would be an unavoidable duplication of the server-side effort, which was usually implemented in some other language.

Then along came Node, presenting the opportunity for server-side JavaScript. This is a great stack, since mental friction is reduced when working on different sides of the codebase if you don’t have to switch languages and tools. Nor should you have to work with different representations of the same domain. To anyone working with this sweet setup, such a duplication of effort should be appalling.

This article outlines an approach that is driven by the desire to ensure that all code in such a system handles entities in the same way with regard to construction, validation, and marshalling by packaging the entities as a separate library, written in framework-agnostic, Universal JavaScript. It may or may not be the most elegant approach for your system’s architecture, depending on the frameworks you use and how prescriptive they are.

Modeling the Domain

Those who employ XML as a means of data exchange often use XML schema definitions as a way of describing the entities that their XML will represent. The beauty of this is that middleware can generate the code to represent those entities, and the XML can easily be validated against the schema. Further, you can produce diagrams that make it far easier to reason about the domain than the schema definition alone.

If you use JSON, schemas can be used as well, but are not as prevalent, probably because (currently) the only good editor is Altova’s XMLSpy 2017, which costs a thousand bucks and only runs on Windows. But with it, you can define your domain graphically, without worrying about the underlying syntax. Here’s an example:

That’s certainly a lot easier to take in than the corresponding JSON schema:

Schema diagrams are useful for understanding and reasoning about complex domain models. The schemas themselves can be used to generate entity representations. But if you don’t have a nice schema editor and/or middleware to generate entity code and/or a system to support validation against a schema, you can just sketch things out on a whiteboard or on index cards until you’re reasonably happy with the model. It’s best to have the entities figured out before you start slinging the code to represent them.

Representing Entities in Code

We need the ability to construct an object with the decided-upon properties using the new keyword or by marshalling from a plain object. Instances should inherit methods from the prototype that can tell you if the object is valid, and marshall it to a plain JavaScript object.

There is a school of thought that says you shouldn’t expose the properties but should instead only mutate them by way of behavioral methods. It diverges somewhat from my goal of sharing validation code across the stack, and focuses instead on making sure the entity cannot get into an invalid state, since domain logic encoded in the behavior methods will always do the right thing with it. Here’s a good take on that approach. It isn’t wholly incompatible with this one, but it is more client-focused.

The definition of the entity is wrapped in an IIFE, and set on a variable that is then set on module.exports or window.User, depending upon the environment we’re running in; Node or the browser. Then the entire business is wrapped in another IIFE, so that the only trace of this code after it has run is what we specifically placed in the global namespace. Tip o’ the old propeller beanie to Matteo Agosti for this part of the solution.

NOTE: In order to avoid conflict with other code in the browser, you might want to further namespace your entities (e.g., window.MyApp.User) instead of sticking them directly into the global namespace. Any code creating a User instance would have to use new MyApp.User() instead of new User(). For this example, I’m doing the simplest possible thing that works in both environments.

Also, notice there are validation methods at both field and instance level. Each field may have different validation rules, such as the email field which has a regex test in addition to making sure it’s populated. And the name field must be a valid instance of NameToken. This allows individual fields on a form to use that validation logic as the form is filled in or modified. The instance-level validation method simply makes sure all the required fields are valid, using calls to the field-level methods. A form could use the instance’s isValid method to control whether the submit button is enabled, while the server uses that same method to make sure the object that was submitted is valid before writing it to the database.

Loading the Entity Prototypes

Now that we have our entities built, we need an easy way of loading them all at once into the browser, or as a module in Node.

Conclusion

The above solution is meant to solve the problem of duplicated validation and marshalling code in an environment where JavaScript is running on both client and server by placing that code on the entity representation itself. It is a framework-agnostic example with no dependencies.

Before choosing your own implementation, consider how your domain model entities will be used rather than taking any one person’s advice. Their approach may be driven by pressures that are not your own.

For instance, with Angular on the client, you might want to use the properties of an entity instance in data-binding expressions on a form, then export a raw object (if the entity is valid) to send to the server. When the server sends you a raw object, you can easily marshall it into an entity instance. If so, the above solution might be a good place for you to start.

React aficionados however, will likely recoil at the idea of directly mutable properties on an object meant to represent an entity, and might be more interested in a framework-specific solution like react-entity, particularly if they are using React on the server, too.

Regardless of how apropos the solution is to your situation, I hope this article helps you think it through, so that your domain model entities will shine like the crown jewels they are.