![]() ![]() The two small microservice components have only different deployment units, which may also have an impact on how they interact. If this is the granularity that you consider a worthy microservice, understand that both the Product microservice and the BacklogItem microservice will still be in the same larger, logical Bounded Context. An example of such a microservice is a Product and another is a BacklogItem. Using that definition, a microservice models only one concept and manages one narrow type of data. Regarding the idea that a BC can also span several processes and physical or virtual machines Vernon gives the following explanation while talking about an example application that deals with Scrum-based software project management: "some consider a microservice to be much smaller than a DDD Bounded Context. For example, a DLL could contain more than one BC and one BC could span several DLLs. So a BC does not equal a package, project or any other kind of deployment artifact. It’s not an individual component, document, or diagram. So it’s not a JAR or DLL, but these can be used to deploy a Bounded Context as described later in the chapter." A Bounded Context does not dictate the creation of a single kind of project artifact. ![]() To add some weight to the argument that it is absolutely not antithesis to DDD for a Bounded Context to span multiple deployment artifacts or processes, here's what Vernon says in 'Implementing DDD': "A Bounded Context does not dictate the creation of a single kind of project artifact. To this I answer, really? Why not? Where in the definitions of a Bounded Context or the Ubiquitous Language do we see any mention of anything that has to do, even remotely, with the concept of deployment location or process boundaries? Nowhere, that's where. Plus, they are separate applications (it's in the name after all), that run on a different machine, surely BCs do not cross process boundaries? A bit like a vertical slice or slices.īut surely Vernon didn't have SPAs in mind when he said this? SPAs are different, they are more than just UI, some even have a bit of business and application logic. When talking about Bounded Contexts, Vernon, at least, is talking about the entire stack. These layers are common in a Bounded Context: Input Adapters, such as user interface controllers, REST endpoints, and message listeners Application Services that orchestrate use cases and manage transactions the domain model that we’ve been focusing on and Output Adapters such as persistence management and message senders." Domain-Driven Design Distilled - Vaughn Vernon What’s inside a Bounded Context? Using this Ports and Adapters architecture diagram, you can see that a Bounded Context is composed of more than a domain model. ![]() He says that "There is another question that you may have wondered about. To those questions, at least, Vernon offers precise and satisfying answers, with an accompanying diagram no less. Is that what Vernon envisions when he sees a BC? Does a BC only contain the classes and interfaces that are part of the domain model (entities, value object, domain services, domain events and repositories) or does it extend to the classes (application services, controllers, etc.) in other layers? My conclusion is influenced by the fact that I'm a full-stack developper and usually work on multi-disciplined teams who do vertical slices.īut what if the people in charge of developing the api/product/:id endpoint are technically not on my team and teams are split between client-side and server-side □? Also, the ProductViewModel might not be a perfect 1 to 1 mapping of the server-side Product entity, doesn't that mean that when I'm thinking of a Product I'm not thinking of exactly the same thing as my server-side brethren? A Bounded Context is composed of more than a domain model.īy that logic though, even in a standard MVC type app, where the pages are rendered on the server, you would have to say that the Bounded Context excludes the Controller, the View and the Model. ![]() I'll admit that due to the abstract nature of the definition of a Bounded Context, someone could arrive at a different conclusion. To my mind, if in the SPA I'm dealing with a ProductComponent, ProductView or ProductViewModel, the data for which I received from the api/product/:id endpoint, endpoint that was custom made for the particular use case served by ProductComponent by members of my team, then we're talking the same Ubiquitous Language. This definition seemed to confirm my intuition that a Single-Page Application(SPA) should be part of the same BC as its server-side API, but does it really? In the previous article in this series we arrived at a simple, but rather abstract definition of what a Bounded Context(BC) is. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |