Skip to main content
Software Engineering

Return to Answer

deleted 1 character in body
Source Link
zafarkhaja
zafarkhaja
  • 297
  • 2
  • 4

OOP

When in doubt I follow 2 simple rules which help me make the right decision

  1. Encapsulation and Information hiding
  2. Low coupling and High cohesion

So this basically means Data + Behavior which you already know. But it also means that it is the class's responsibility to maintain the state of its instances, that is when you instantiate an object you should get a valid object with a valid state. These principles can be easily applied to modules and layers as well.

Validation

I can think of 2 different types of validation:

  1. Data validation (aka Input validation)
  2. Business Rules validation (your case)

As their names imply, unlike the former the latter should belong in the Domain Model containing all the business logic. EventEven if you use Factories and Builders to build your objects and carry out some validation there you still do it in the Domain Model. I liked the Input Validation vs. Business Rules Validation article on the subject.

Back to your question. Can [Business Rules] validation be considered as an object behavior? I would say it can but I tend to think of it as an act of maintaining an object's consistency. It's somewhat different from messages (Behavior) you send to objects in that validation is mostly hidden from the outer world and can't be triggered directly.

P.S. One way to solve your problem with "invalid" data is to have different models (CQRS) for read and write with the read model having looser requirements than that of the write model.

OOP

When in doubt I follow 2 simple rules which help me make the right decision

  1. Encapsulation and Information hiding
  2. Low coupling and High cohesion

So this basically means Data + Behavior which you already know. But it also means that it is the class's responsibility to maintain the state of its instances, that is when you instantiate an object you should get a valid object with a valid state. These principles can be easily applied to modules and layers as well.

Validation

I can think of 2 different types of validation:

  1. Data validation (aka Input validation)
  2. Business Rules validation (your case)

As their names imply, unlike the former the latter should belong in the Domain Model containing all the business logic. Event if you use Factories and Builders to build your objects and carry out some validation there you still do it in the Domain Model. I liked the Input Validation vs. Business Rules Validation article on the subject.

Back to your question. Can [Business Rules] validation be considered as an object behavior? I would say it can but I tend to think of it as an act of maintaining an object's consistency. It's somewhat different from messages (Behavior) you send to objects in that validation is mostly hidden from the outer world and can't be triggered directly.

P.S. One way to solve your problem with "invalid" data is to have different models (CQRS) for read and write with the read model having looser requirements than that of the write model.

OOP

When in doubt I follow 2 simple rules which help me make the right decision

  1. Encapsulation and Information hiding
  2. Low coupling and High cohesion

So this basically means Data + Behavior which you already know. But it also means that it is the class's responsibility to maintain the state of its instances, that is when you instantiate an object you should get a valid object with a valid state. These principles can be easily applied to modules and layers as well.

Validation

I can think of 2 different types of validation:

  1. Data validation (aka Input validation)
  2. Business Rules validation (your case)

As their names imply, unlike the former the latter should belong in the Domain Model containing all the business logic. Even if you use Factories and Builders to build your objects and carry out some validation there you still do it in the Domain Model. I liked the Input Validation vs. Business Rules Validation article on the subject.

Back to your question. Can [Business Rules] validation be considered as an object behavior? I would say it can but I tend to think of it as an act of maintaining an object's consistency. It's somewhat different from messages (Behavior) you send to objects in that validation is mostly hidden from the outer world and can't be triggered directly.

P.S. One way to solve your problem with "invalid" data is to have different models (CQRS) for read and write with the read model having looser requirements than that of the write model.

added 13 characters in body
Source Link
zafarkhaja
zafarkhaja
  • 297
  • 2
  • 4

OOP

When in doubt I follow 2 simple rules which help me make the right decision

  1. Encapsulation and Information hiding
  2. Low coupling and High cohesion

So this basically means Data + Behavior which you already know. But it also means that it is the class's responsibility to maintain the state of its instances, that is when you instantiate an object you should get a valid object with a valid state. These principles can be easily applied to modules and layers as well.

Validation

I can think of 2 different types of validation:

  1. Data validation (aka Input validation)
  2. Business Rules validation. (your case)

As their names imply, unlike the former the latter should belong in the Domain Model containing all the business logic. Event if you use Factories and Builders to build your objects and carry out some validation there you still do it in the Domain Model. I liked the Input Validation vs. Business Rules Validation article on the subject.

Back to your question. Can [Business Rules] validation be considered as an object behavior? I would say it can but I tend to think of it as an act of maintaining an object's consistency. It's somewhat different from messages (Behavior) you send to objects in that validation is mostly hidden from the outer world and can't be triggered directly.

P.S. One way to solve your problem with invalid"invalid" data is to have different models (CQRS) for read and write with the read model having looser requirements than that of the write model.

OOP

When in doubt I follow 2 simple rules which help me make the right decision

  1. Encapsulation and Information hiding
  2. Low coupling and High cohesion

So this basically means Data + Behavior which you already know. But it also means that it is the class's responsibility to maintain the state of its instances, that is when you instantiate an object you should get a valid object with a valid state. These principles can be easily applied to modules and layers as well.

Validation

I can think of 2 different types of validation:

  1. Data validation (aka Input validation)
  2. Business Rules validation.

As their names imply, unlike the former the latter should belong in the Domain Model containing all the business logic. Event if you use Factories and Builders to build your objects and carry out some validation there you still do it in the Domain Model. I liked the Input Validation vs. Business Rules Validation article on the subject.

Back to your question. Can [Business Rules] validation be considered as an object behavior? I would say it can but I tend to think of it as an act of maintaining an object's consistency. It's somewhat different from messages (Behavior) you send to objects in that validation is mostly hidden from the outer world and can't be triggered directly.

P.S. One way to solve your problem with invalid data is to have different models (CQRS) for read and write with the read model having looser requirements than that of the write model.

OOP

When in doubt I follow 2 simple rules which help me make the right decision

  1. Encapsulation and Information hiding
  2. Low coupling and High cohesion

So this basically means Data + Behavior which you already know. But it also means that it is the class's responsibility to maintain the state of its instances, that is when you instantiate an object you should get a valid object with a valid state. These principles can be easily applied to modules and layers as well.

Validation

I can think of 2 different types of validation:

  1. Data validation (aka Input validation)
  2. Business Rules validation (your case)

As their names imply, unlike the former the latter should belong in the Domain Model containing all the business logic. Event if you use Factories and Builders to build your objects and carry out some validation there you still do it in the Domain Model. I liked the Input Validation vs. Business Rules Validation article on the subject.

Back to your question. Can [Business Rules] validation be considered as an object behavior? I would say it can but I tend to think of it as an act of maintaining an object's consistency. It's somewhat different from messages (Behavior) you send to objects in that validation is mostly hidden from the outer world and can't be triggered directly.

P.S. One way to solve your problem with "invalid" data is to have different models (CQRS) for read and write with the read model having looser requirements than that of the write model.

Source Link
zafarkhaja
zafarkhaja
  • 297
  • 2
  • 4

OOP

When in doubt I follow 2 simple rules which help me make the right decision

  1. Encapsulation and Information hiding
  2. Low coupling and High cohesion

So this basically means Data + Behavior which you already know. But it also means that it is the class's responsibility to maintain the state of its instances, that is when you instantiate an object you should get a valid object with a valid state. These principles can be easily applied to modules and layers as well.

Validation

I can think of 2 different types of validation:

  1. Data validation (aka Input validation)
  2. Business Rules validation.

As their names imply, unlike the former the latter should belong in the Domain Model containing all the business logic. Event if you use Factories and Builders to build your objects and carry out some validation there you still do it in the Domain Model. I liked the Input Validation vs. Business Rules Validation article on the subject.

Back to your question. Can [Business Rules] validation be considered as an object behavior? I would say it can but I tend to think of it as an act of maintaining an object's consistency. It's somewhat different from messages (Behavior) you send to objects in that validation is mostly hidden from the outer world and can't be triggered directly.

P.S. One way to solve your problem with invalid data is to have different models (CQRS) for read and write with the read model having looser requirements than that of the write model.