Are the domain classes a component ?
A component is something self-contained and substitutable with well defined interfaces:
A Component is a self-contained unit that encapsulates the state and
behavior of a number of Classifiers. A Component specifies a formal
contract of the services that it provides to its clients and those
that it requires from other Components or services in the system in
terms of its provided and required Interfaces.
A Component is a
substitutable unit that can be replaced at design time or run-time by
a Component that offers equivalent functionality based on
compatibility of its Interfaces.
- UML 2.5 standard, section 11.6.3.1, Semantics of components
But interfaces are however not necessarily to be conceived as a technical artifact, like a java interface:
An Interface specifies a contract; any instance of a Classifier that
realizes the Interface shall fulfill that contract. The obligations
associated with an Interface are in the form of constraints (such as
pre- and postconditions) or protocol specifications, which may impose
ordering restrictions on interactions through the Interface.
- UML 2.5 standards, section 10.4.3.1, Semantics of interfaces
Your domain classes should be self-contained, substitutable and have clear interfaces, so you can consider them as a component:
- Self-contained: there is no reason that they would depend on anything else of
ExamResults and ExamResultsDAO.
- Interfaces: those used by
ExamResults and ExamResultsDAO (either explicit interface, or implicit via their public elements)
- Substitutable: you could replace their implementation with another as long as you respect the same interfaces to offer the same behavior.
Should the component stand on its own ?
Your ExamResults service offers an application service, which is to read JSON data and store it to a database. To perform its work it needs:
- a request handler: depends on the interface and protocols supported by the application service (e.g. HTTP requests ? SOAP messages ? Remote function calls ?)
- a parser: depends on the format used for the exams. Here you go for JSON. Tomorrow you may go for XML because you have to interconnect with another system of another university.
ExamDAO: depends on the database used. THe DAO classes would not be implemented in the same way, if it's an SQL database or a NoSQL database (e.g. key-value store, graph database, or document based database). - Domain model: depends solely on the domain model and neither on the data format, nor on the technical protocols, nor on the DBMS used
This suggests that there are big advantage to isolate the domain model from the rest, in order to enforce separation of concerns.
Well, it would have been much faster to point at clean architecture to support come to this conclusion. However all this reasoning is valid whatever other architecture model you may have chosen.
Additional thoughts
Your microservice does only a small task in a broader system. Other microservices might use the data in the database and perform other tasks. It could be tempting then to reuse the domain classes, and the DAO classes in this context. For school project it's nice. However, be cautious:
- microservice are intended to be as decoupled as possible. Sharing of common code creates however a hidden coupling between things that should remain independent, which may require constraints for the deployment of new releases.
- in a microservice landscape, the shared database creates an even stronger coupling between services. For big data applications it can also become a bottleneck, as it may limit scalability.
