DTOs are not part of the domain model, and do not have any behaviour. DTOs represent the data structures that are transferred across your system boundary, e.g. data that is serialized to be sent across a network. DTOs are also great for representing incoming data that is possibly inconsistent, before it is validated and translated to your domain model.
Within the domain model, the objects representing the concepts within the problem domain do typically contain associated business logic. The interesting part isn't behaviour that queries the state of the model, but methods that change the model, beyond simple setters. This can lead to a very elegant mapping of the problem domain into your code because the model basically manages itself.
Sometimes we don't want to do that, and keep most behaviour out of the immediate model. This is called an anemic domain model, and is a more procedural than object-oriented design technique. As such, it is considered to be an anti-pattern by some. However, this works very well if there is a lot of business logic that doesn't clearly belong to a single domain model object. Instead, we can structure the business logic by use case. Each use case then manipulates the domain model. The drawback is that it becomes more difficult to keep the model consistent.
These two approaches are not exclusive, but are a sliding scale. At one end, all behaviour is directly in the model, at the other the domain model consists of dumb records. In the middle, the domain model contains generic operations that ensure consistency, but specialized logic lives outside in services which orchestrate changes to the model.
In your case, an
isMarried() accessor has nothing to do in a DTO. A DTO can just expose its data. Within your domain model, it seems that such a method clearly belongs to some kind of Person class. If you are introducing Util classes that are named after another class, that is a clear warning sign that your design might be off: in many cases that behaviour should be part of the original class or else should be modelled separately as it's not part of the modelled problem domain.
However, I think that an
isMarried() accessor is a weak example of this because it's basically just a getter, and a getter is basically just fancy syntax for a field. As a different example, let's consider a web application that allows students to enrol in lectures. If this is directly part of the domain model, we would see method calls like
lecture.enrol(student) in our code. But sometimes enrolment isn't simple and has complex business rules, e.g. how limited seats are given to the applying students. If enrolling is a whole process of its own, we might want to model that process as a separate object:
lectureEnrolmentProcess.run(lecture, student). Coming back to your
isMarried() behaviour: since this behaviour likely isn't a complex process with its own concerns, it shouldn't be kept separate.
So I think there should be a clear bias to put most behaviour directly into the model, but we shouldn't be afraid to extract any behaviour that has an entirely different concern than the concept being modelled.