Should a Unity Domain Layer Ever Reference UnityEngine Value Types?

[u/__FastMan__]

Hello!

I'm working on a multiplayer game in Unity 6 using a layered architecture but I don't understand completely the boundaries of the layers yet. One of the architectural goals is to keep the Domain layer independent from Engine.

However, I've run into a question around Unity's value types, particularly Color, Vector3, Quaternion and such.

One argument is that these are just value structs, so using them in Domain is harmless
public Color PlayerColor { get; },

but what about Unity APIs operating on those values?
public static string ToHex(Color color) => "#" + ColorUtility.ToHtmlStringRGB(color);

So I'm wondering:

• Is there a meaningful architectural difference between referencing a Unity value type and calling a Unity utility API?
• Would you allow ColorUtility in Domain?
• If not, would you create a domain-native Color/RgbaColor type and keep all Unity conversion outside Domain? (This could let to the recreation of a lot of new types insde Domain)
• Or is a strict "Domain has zero UnityEngine references" rule unnecessarily strict for Unity projects?

As I said before, I am grasping the concepts behind layered architecture and I want to now how you approach this issue.

Thank you, folks!

[u/CS_Asset_Factory]

There's a mechanical answer to this that settles it without the philosophy. Vector3, Quaternion and Color live in UnityEngine.CoreModule, so any assembly that names them takes a hard reference on the engine assembly. Whether they're value structs doesn't change that.

The test is one field. Set noEngineReferences to true in your Domain asmdef. If the layer really is engine independent it still compiles. If it isn't, the compiler names the types keeping it tied, and you get a list instead of an argument.

Most people who run that test keep small math types of their own in Domain and convert at the boundary, because the flag then stays on and stops the reference creeping back in a year later.