Now that we have identified the teams, and also sort of identified their focused and main set of requirements to let them work on their objects, let's narrow it down to the technical design of the individual team level.

Naturally, we followed the DDD methodology, or at least some stripped version of the DDD sets of processes, and there we have identified our contextual teams and processes. Let's assume that our teams, as identified previously, fit the single bounded context per team on the basis of the business and technical domains having their own special needs, and therefore, could have their own segregated IT systems and databases.

Since we are building the Microservices-based architecture at this stage, and for the sake of coverage in the book, we won't go into the granular business requirements and into details of insider implementation of each microservice and the number of interfaces it could contain.

We consider this as a microservices-based architecture, and not the design and architecture for the internal components and service interfaces of each microservice and their implementation details. Note that microservices-based architecture gives full independence to the teams, both technical and business, to come up with their own strategy, design, technology and implementation of their bounded contexts inside a container, but only having agreed on the exposed microservices interfaces and standard communication patterns and mechanisms.

So we have decided to develop and deploy at least one container per context as per our architecture, and at least two containers for each team's context (for UI and for system interfaces). Since implementation inside each container is technologically independent, and each microservice from the given view is technology agnostic, every team is free to implement their container in the technologies that they prefer fit. For example, the sales team could use the LAMP stack inside their container, while the marketing team used the MEAN stack, and the publishing team the .NET Core-based stack for technical implementation.

Let's assume that after some discussions, we have decided to use an industry leading CRM (Customer Relationship Management) system, and to integrate it with our set of interfaces. The CRM system would be primarily used by the sales team. We also assume that since it's a market leading CRM, it exposes a set of APIs that allow us to integrate our custom code to this CRM both for read and write operations. If, for any reason, our chosen CRM system does not expose APIs or web services, we will have to wrap those components and convert them as callable APIs over HTTP and/or over Message Queue. This newly exposed API project could either be developed as a Web API inside the Azure cloud, or, depending on our architecture, it could be developed as a separate microservice inside its own unique container.