I'm building a utility/support assembly that maintains data & state for any tile-based board game: it should be able to model everything from checkers and chess to a Civilization-esque game (no visuals, just state & data). They're just boards with height, width, and stuff that goes on the board.

Consumers of the assembly wont have access to domain object instances, but will have lists of ids for the various entities active in the model. The public interface is in domain terms only (create a boardpiece, move a boardpiece, set value for an attribute of a boardpiece, etc).

I'm stumbling on the internal implementation: is it sounder for domain objects to have references to each other (easier to code, but could also result in code that invalidates the model; a BoardTile shouldn't mutate the Boardpiece it may contain), or to mirror the public interface, and only reference other objects by "domain entity id" (seems overly restrictive, and a little more work to implement, but may be better for enforcing compliant code)?

Might have answered my own question: why create two different systems for the same thing? If I'm going to build the id-based system for the external interface, might as well use it internally as well.

Does this seem reasonable? Seems reasonable to me...

It depends a lot on the game and the engine.

In my experience, game engines that allow the player to load/save at any time also have a side effect that most code must use IDs rather than pointers. In this type of engine you can only use pointers for 'instant' processing, for calls that are run immediately and never yield control back for animations or other events. In this scenario a pointer for any non-instant processing will not persist properly between saves and can become invalid unexpectedly.

Because of that, I am in the habit of using handles or IDs for everything.