what is (and isn’t) domain logic
It seems that a lot of stuff ends up in “domain” or “business” objects that is not actually domain logic. I’ve done this myself, but i always find it something painful about it. There’s always this nagging feeling that something is wrong.
Here is my list of things that don’t belong in your domain objects.
1) Primitive comparison operations - For example, equals methods that compare a bunch of value type members on your domain objects.
2) Primitive range checking operations - For example, manually validating that a string description is above 100 chars and under 1000.
3) (De)Serialization code.
4) Database 0/R mapping code - by this i mean code that directly references a particular database and/or its stored procedures, tables, columns, etc… you see often see this in “Business Objects” that contain methods like “Load” and “Save”. Sometimes there is an intermediate adapter that provides loosely coupled access to the database. Still, you have the business layer making assumptions and putting constraints on how the database will be accessed. It’s very problematic.
5) User interface code - that is any code refering to windows forms or html, etc…
6) Networking code - does your business layer know whether you are using soap, binary, tcp, http, etc? If so, you have this problem.
If you get all of this stuff away from your domain objects, you might find there isn’t much left. Here is my list.
1) Data Model Definition - classes whose interface describes the NOUNS in your application and their structure.
2) Service Model Definition - classes whose interface describes the VERBS in your application and their structure. Contrary to popular belief, I think the Service Model Definition is far more important than the Data Model Definition. The Service Model Definition leads you to the Data Model Definition, but more on that later.
3) Validation Rules Specification - validation rules for the data model and the service model. This is where you STATE that the minimum number of chars for the description is 100 and the maximum is 1000. You do not implement this code using the greaterthan/less than operators in your language. That will lead to much suffering.
4) User Interface Workflow Definition - a description (in code) of how the users should be asked to enter complex information. I used to think that this was part of the presentation layer, but I since have changed my mind. Its hard to think of many things that are more unique to the problem domain than the sequence of choices users have to make to use the program. Workflow should be easy to evolve according to changes in the business. The presentation layer should be for manipulating controls so that they are stylish and responsive, etc… Workflow should be part of the domain layer.
5) The implementation of Complex Calculations and Validations that are truly specific to your problem domain - I think these are much more rare than people claim. How many applications actually have logic that cannot be captured with generic rules and validation constraints? Most of the time the content and the data structure is what users are interested in. Of course some systems have proprietary calculations and what not. Obviously these belong in your domain layer.