Once refactored, it’s important to govern the component domains to ensure that namespace rules are enforced and that no code exists outside the context of a component domain or subdomain. The following automated fitness function can be used to help govern component domains once they are established within the monolithic application.
Fitness function: All namespaces under should be restricted to This automated holistic fitness function can be triggered on deployment through a CI/CD pipeline to restrict the domains contained within an application. This fitness function helps prevent additional domains from being inadvertently created by development teams and alerts the architect if any new namespaces (or directories) are created outside the approved list of domains. Example 5-10 shows an example using ArchUnit for ensuring that only the ticket, customer, and admin domains exist within an application.
Example 5-10. ArchUnit code for governing domains within an application public
void
restrict_domains
()
{
classes
()
.
should
().
resideInAPackage
(
"..ss.ticket.."
)
.
orShould
().
resideInAPackage
(
"..ss.customer.."
)
.
orShould
().
resideInAPackage
(
"..ss.admin.."
)
.
check
(
myClasses
);
}
Sysops Squad Saga: Creating Component Domains
Thursday, November 18, 13:15
Addison and Austen consulted with Parker, the Sysops Squad product owner, and together they identified five main domains within the application: a Ticketing domain (ss.ticket) containing all ticket-related functionality, including ticket processing, customer surveys, and knowledge base (KB) functionality; a Reporting domain (ss.reporting) containing all reporting functionality; a Customer domain (ss.customer) containing customer profile, billing, and support contracts; an Admin domain (ss.admin) containing maintenance of users and Sysops Squad experts; and finally, a Shared domain (ss.shared) containing login and notification functionality used by the other domains.
Addison created a domain diagram (see Figure 5-19) showing the various domains and corresponding groups of components within each domain, and was satisfied with this grouping as no component was left out, and there was good cohesion between the components within each domain.
The exercise Addison did in diagramming and grouping the components was an important one as it validated the identified domain candidates and also demonstrated the need for collaboration with business stakeholders (such as the product owner or business application sponsor). Had the components not lined up properly or Addison was left with components that didn’t belong anywhere, more collaboration with Parker (the product owner) would have been necessary.
Satisfied that all of the components fit nicely into these domains, Addison then looked at the various component namespaces in Table 5-12 after applying the “Flatten Components Pattern” and identified the component domain refactoring that needed to take place.
Figure 5-19. The five domains identified (with darkened borders) within the Sysops Squad application
Addison started with the Ticket domain and saw that while the core ticket functionality started with the namespace ss.ticket, the survey and knowledge base components did not. Therefore, Addison wrote an architecture story to refactor the components listed in Table 5-15 to align with the ticketing domain.
Table 5-15. Sysops Squad component refactoring for the Ticket domain Component
Next Addison considered the customer-related components, and found that the billing and survey components needed to be refactored to include them under the Customer domain, creating a Billing subdomain in the process. Addison wrote an architecture story for the refactoring of the Customer domain functionality, shown in Table 5-16.
Table 5-16. Sysops Squad component refactoring for the Customer domain Component
By applying the “Identify and Size Components Pattern”, Addison found that the reporting domain was already aligned, and no further action was needed with the reporting components listed in Table 5-17.
Table 5-17. Sysops Squad Reporting components are already aligned with the Reporting domain Component
Addison saw that both the Admin and Shared domains needed alignment as well, and decided to create a single architecture story for this refactoring effort and listed these components in Table 5-18. Addison also decided to rename the ss.expert.profile namespace to ss.experts to avoid an unnecessary Expert subdomain under the Admin domain.
Table 5-18. Sysops Squad component refactoring for the Admin and Shared domains Component
Domain
Current namespace
Target namespace
Login
Shared
ss.login
aa.shared.login
Notification
Shared
ss.notification
ss.shared.notification
Expert Profile
Admin
ss.expert.profile
ss.admin.experts
User Maintenance
Admin
ss.users
ss.admin.users
With this pattern complete, Addison realized they were now prepared to structurally break apart the monolithic application and move to the first stage of a distributed architecture by applying the Create Domain Services pattern (described in the next section).
