C# – Microservice and anti-pattern

cdomain-driven-designdomain-modelmicroservices

I am doing a microservice and I was trying to make a decision about how to handle Domain Model.
I am planning to have multiple microservices, as an example: A ClientsMS and a PaymentMS. They both need to have a client class. One way is to have client class in both MS and do a mapping between the two, Or have a Model(domain) Microservice which will have client and other classes, and this will be consumed via DLL.
I am not sure f by using DLL I am introducing an anti pattern. but also using Domain model in every MS I will be loosing the SRP and DRY.

Best Answer

Microservices have a very nice connection to DDD: in a sensible architecture, every microservice will handle a single bounded context.

Every bounded context has its own problem domain and therefore its own model. Instead of sharing parts of the model, keep the model nicely decoupled and translate between models. For microservices, the context boundary corresponds to the input/output of the microservice. You gain nothing by creating a model-microservice or sharing a common model-DLL because no common model exists. A client might be a “user account” in a user service context and a “credit card + billing address” in a payment service context. Just because they are somehow connected does not mean that you should represent them via a single entity in all contexts.

But speaking in practical terms, it can make sense to share a DLL that contains the DTOs and their serialization/deserialization. These DTOs do not represent the model of any context, but only the communication between your microservices. A shared library makes sure that serialization is always done correctly by avoiding repeated code, and it lets your services consume a strongly typed interface. The downside is this reduces one major benefit of microservices: technology-agnosticism. A common library also implies that deployments of new versions need to be synchronized.

Related Solutions

Visual Studio – Organizing Solutions for Microservices

We ultimately found that decisions made about the devops pipeline and the microservices platform will likely dictate how the Visual Studio projects and solutions are organized.

Initially, we decided one solution per microservice was the best way to go. Any common "core" libraries also had their own solutions. "Core" libraries were then hosted via internal nuget feeds for consumption by any service. This gave us the flexibility to keep services on old versions of libraries if necessary. Had we settled on Docker Swarm or Kubernetes as a platform, I think this "solution-per-service" decision would have worked out fine. However, we ended up choosing Service Fabric, which impacted our decision.

In Service Fabric, an "application" hosts a "service" (I encourage you to read more about the nomenclature if you are interested in this option). The Visual Studio solution has to be tailored somewhat to accommodate these dependencies. Depending on how you plan to scale your services, "solution-per-service" may not be an option (for reasons outside the scope of this answer).

In conclusion: pick your platform and your devops first. I think solution-per-service is ideal, but the logistics of your platform may be prohibitive.

Architecture – Domain Model Design – Best Practices for Robust Fluency, Encapsulation, and Extensibility

Frankly, glue classes that merely pass through fields from the data model don't really add significant value to your application, nor are they particularly interesting from a functional perspective.

So before we get too deeply into your individual questions, let me propose a simple foundational architecture:

DB <---> ORM <---> SL/BLL <---> VM <---> V

The DB is your database. The ORM is your Object-Relational Mapper; it communicates with the database via SQL, and exposes CRUD methods. The SL/BLL is your Service Layer/Business Logic Layer; it converts business operations such as CreateInvoice into CRUD methods for consumption by the ORM. The VM is the ViewModel; it coordinates UI interaction with the SL/BLL. The V is the View; it contains surface-level UI interaction and validation code-behind.

Your sample code is suggestive of C#. In C#, your ORM (very likely Entity Framework) can produce code-generated entity classes that can be glued to domain logic using the partial keyword, allowing you to write custom domain and validation logic for each entity class without the pain of creating all that boilerplate for DTO's.

A lean architecture like this one should allow you to develop an easily maintainable application with the minimum necessary boilerplate code. Unless you're building an elaborate, crystal-cathedral architecture in Java for a large development team, this representative architecture should be all of the abstraction you will ever need.

Best Answer

Related Solutions

Visual Studio – Organizing Solutions for Microservices

Architecture – Domain Model Design – Best Practices for Robust Fluency, Encapsulation, and Extensibility

Related Topic