Generally you don't keep them in sync in that way unless there is a reason to do so. Your entire premise is flawed. Most of the domain logic in an SPA, like any application, should be in the server. Only logic pertaining to the user interface should be in the client.
So just to be clear on terminology. I assume that when you say "domain logic" you mean the core business logic of the application, the thing that makes your application more than just CRUD operations on resources. It may very well be that your application only needs to store, retrieve, update, and delete some data, in which case I suppose all of the "logic" would be in the client.
But imagine a simple purchasing system where you have inventory items and users are able to add items to a shopping cart for purchase. Imagine then that you need to know whether or not an item is in inventory or out of stock and if it's out of stock your particular use case does not allow a purchase to take place on an out-of-stock item. In this scenario I don't think you would be doing the right thing if you did not have this requirement checking logic in your back-end.
You would certainly want to disable the "Buy Now" button on the client if the item was out of stock, but allowing the back-end to process a purchase for the out of stock item simply because an enterprising teenager decided to submit a POST request using curl seems very wrong to me.
The reason for the client to know that the item is out of stock is different from the reason for the back-end to know it. The client needs to know it to disable a button but the back-end needs to know it to prevent an incorrect charge.
The client's model of the state of the system might just include a purchasable boolean if that is all that is needed, while the server's model may have to take into account a wide variety of reasons, not just whether or not the item is in stock--perhaps the item is not shippable to the current user's location or perhaps the current user has a 35% coupon in their account and the margin on the item is less than 35%. Chances are that the reasons for an item being purchasable or not is more complex to the server than the client, and it's very unlikely that a business system would allow the business logic to be made available to anyone who can download the JS files for the site (every visitor!).
Perhaps the server in that case simply removes the item from the list of results in a query for the purchasable items. The client cannot by definition apply any business domain logic to this item because it does not know that the item exists in the first place.
What if you next want to deploy a native mobile application? Are you going to recreate all of your business domain logic in each new client? What if the system has gotten so large that there are hundreds of rules?
One of the key takeaways of experienced software developers should be that there can and will be multiple models in a system.