After working with domains for several years I find that there are three major categories of objects I work with: Entities, Services, and Resources. There are clear distinctions between these categories in their purpose, content, dependencies and roles. Understanding these categories clarifies what dependencies I should allow, what purpose the objects serve, and how I should test them.<\/p>\n
Entities<\/em> are the domain objects. They model the data that gets persisted to the database. These objects are mostly data, and have little behavior.<\/p>\n Services<\/em> are the workhorses of the application. They perform the majority of the business logic. These objects have little to no state, and are almost pure behavior.<\/p>\n Resources<\/em> are the objects that interface with outside dependencies like the file system, database, etc. These objects only have the business logic necessary to interface with these outside dependencies. They are used to decouple the application from the dependency itself. A good example of a resource is a repository\u00e2\u20ac\u201dwhich serves as the source for entities.<\/p>\n Entities<\/em> only have dependencies on other entities through relationships, such as, an order having line items. An entity should never depend on services or resources.<\/p>\n Services<\/em> can depend on anything. Services require dependencies on other services or resources to perform complex tasks\u00e2\u20ac\u201dper the Single Responsibility Principle.<\/p>\n Resources<\/em> generally only depend on the underlying subsystems they are encapsulating. Resources don\u00e2\u20ac\u2122t depend upon other services, but may depend upon other resources.<\/p>\n Entities<\/em> require the least amount of testing. They are mostly data and have simple behavior\u00e2\u20ac\u201dthere is little to test. But entities are used heavily in testing other objects. The serve as input and expected values when testing services and resources. Because there is so little behavior, it is easiest to use entities directly in the tests rather than mock them. (This is where frameworks like <\/em>Fluency<\/em><\/a> come into play to help create these objects in a state containing valid anonymous data. What mocking is to Services and Resources, Fluency is to Entities.)<\/em><\/p>\n Services<\/em> require a great deal of testing since they are mostly behavior. Unit testing them requires mocking any other services or resource they depend on. Any entities needed to test them are created and used directly. <\/p>\n Resources<\/em> cannot be covered in unit tests. Because they interact with underlying systems (disk, database, network, etc), any test against them is, by nature, an integration test. Resources are always mocked when unit testing other objects since they represent dependencies that we want to decouple our tests from.<\/p>\n Entities<\/em> are the core of the Domain Model. They represent the business domain directly.<\/p>\n Services<\/em> can be part of the domain model or a part of the infrastructure model depending on the behavior they are supporting. For instance, a notification service would be an infrastructure concern while a loan calculation service would be a business domain concern.<\/p>\n Resources<\/em> are always part of the infrastructure for obvious reasons.<\/p>\n Are there any other observations you can make about these three types of objects that can help us in our thinking? If so, please add your comments. I would love to hear them.<\/p>\n -Chris<\/p>\n","protected":false},"excerpt":{"rendered":" After working with domains for several years I find that there are three major categories of objects I work with: Entities, Services, and Resources. There are clear distinctions between these categories in their purpose, content, dependencies and roles. Understanding these categories clarifies what dependencies I should allow, what purpose the objects serve, and how I […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[6,47,7,5,8],"tags":[72,92,78,77,71],"class_list":["post-208","post","type-post","status-publish","format-standard","hentry","category-design","category-mocking","category-patterns","category-principles","category-testing","tag-design","tag-mocking","tag-patterns","tag-principles","tag-testing"],"aioseo_notices":[],"_links":{"self":[{"href":"http:\/\/architester.com\/blog\/wp-json\/wp\/v2\/posts\/208","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/architester.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/architester.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/architester.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"http:\/\/architester.com\/blog\/wp-json\/wp\/v2\/comments?post=208"}],"version-history":[{"count":2,"href":"http:\/\/architester.com\/blog\/wp-json\/wp\/v2\/posts\/208\/revisions"}],"predecessor-version":[{"id":210,"href":"http:\/\/architester.com\/blog\/wp-json\/wp\/v2\/posts\/208\/revisions\/210"}],"wp:attachment":[{"href":"http:\/\/architester.com\/blog\/wp-json\/wp\/v2\/media?parent=208"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/architester.com\/blog\/wp-json\/wp\/v2\/categories?post=208"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/architester.com\/blog\/wp-json\/wp\/v2\/tags?post=208"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Dependencies<\/h3>\n
Testing<\/h3>\n
<\/h3>\n
Architecture<\/h3>\n
Other<\/h3>\n