Where does my domain logic go?

I see sometimes debates sparking over smart UIs and where domain logic should go. My view has always been that your domain logic is everywhere. User experience is as much part of your domain as logical structure of your database. But what I noticed is there’s an interesting fluidity that work on Scalability exposes: certain domain logic is sometimes a Presentation concern, sometimes –  Application Services and sometimes – both.

A good counter-example is validation: you really want to give the user feedback early and often, is it a Presentation concern then? Where do error messages get defined? The answer in both cases – it belongs in  Domain layer, but it has to be sufficiently abstract to allow for flexibility that Presentation requires. This I see done wrong all the time, with fancy frameworks and lot of pride taken in doing it, but that’s for another post.

Going back to the original point, Scalability requires that you do as much work as possible when the user is not looking. That tends to shift a lot of what normally would go in Presentation into Application Services layer and a different tier. That means having a separate “bounded context” within your domain layer to keep the state for Presentation layer for immediate and fast consumption.

This is not unexpected, but you don’t think about it until you have to serve a lot of domain logic quickly.

So the answer is – it’s everywhere, with different aspects captured in different layers.

Where does my domain logic go?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s