The relationship between limited context

Question

I have a WinForms application which I hope will be refactoring for using DDD architecture. Firstly, I’m trying to really wrap my head around architecture itself, I have a book by Evans, and I have a book by Vernon, and I am in abundance with three scenarios that I would immediately encounter in my application. I am afraid that I might think or be too strict in the conceptual design process.

1.) Using the example provided in the Pluralsight DDD textbook, he concluded that various limited contexts should be represented by their own decision. However, if I have a winforms application that is not service oriented (this will eventually change, and many of this will become controversial), this is not possible. Therefore, I work under the assumption that I will separate them into different projects / namespaces that are vigilant, there are no interdependencies. Is it right to think about it, or am I missing something obvious?

2.) I have a navigation interface that launches other modules / windows that will belong to separate presentation layers of different limited contexts. Think of the first window that will open when the ERP application starts. Since this does not correspond to a pure any specific aircraft, something like that was correctly implemented. Should this fall into the common core?

3.) I have a limited management job context and a limited Rating / Costing context. This is part of the business process when, when creating a task, its data is then evaluated. It has its own interface, etc., which I feel pretty good that this presentation still adequately falls into the context of task management. However, the actual process of evaluating this data should definitely not. I'm not quite sure how to communicate with the Rating / Costing context, since bc should be kept separate from each other. I understand that I can do messaging, but it seems to be too much for an unallocated application. Each BC could really use some kind of API on its own, but again this seems unnecessary, although this would allow the team to move well to the transition to a distributed architecture later. Finally, my last idea is related to some kind of common dependency, which is an event repository. I don't know if this matches up with domain events, as they seem to have a separate concern in their own right. Does this mean that it will fall under a shared kernel or some other type of solution?

Thanks in advance.

Answer 1

1) A BC manual that is consistent with the decision is only a guide and not a strict rule. However, it provides much-needed insulation. You can still have this with the WinForms project. For example, suppose you have a BC called Clients. Create a solution for it and inside it, create an additional project called Customers.Contracts. This project actually contains the public contract of BC, which consists of DTO, teams and events. External BCs should be able to communicate with BC clients using only messages defined in this draft contract. Ask WinForms to access the Customer.Contracts project, not the client.

2) The user interface often serves as a composition, organizing many BC - composite interfaces. A stereotypical example is the Amazon product page. Hundreds of services from different BCs are required to display the page.

3) Again, this looks like a script that requires a composite interface. The presentation layer can mediate between different BCs. CDs are loosely coupled, but there are still relationships between CDs. Some of them are upstream of others, some upstream, or even both. Each of them has an anti-corruption layer, a port, for integration with related BCs.

Answer 2

First of all, since I saw you talking about the message bus, I think we need to talk about BC integration first.

You do not need a message bus for communication between the BC; here is an explanation of how I integrate various BCs:

I reveal some public interfaces on each BC (like domain commands - requests and events) and has an intermediate level in my infrastructure that transfers this call to another BC.

Here is an example interface for open commands in BC:

public interface IHandleCommands { void DoSomething(Guid SomeId,string SomeName); } 

I also have a similar one for open events

 public interface IPublishEvents { void SomethingHappened(Guid SomeId,string SomeName); } 

Finally, for my open data (i.e. queries in CQ (R) S), I have a different interface, note that this allows you to remove the connection between your domain model and the request code at any time.

 public interface IQueryState { IEnumerable<SomeData> ActiveData(DateTime From=DateTime.Minvalue, ... ); } 

And my implementation looks like this:

 public class SomeAR:IHandleCommands { IPublishEvents Bus; public SomeAr(IPublishEvents Bus) { this.Bus = Bus; } public void DoSomething(Guid x,string y) { Bus.SomethingHappened(SomeId: x,SomeName: y); } } 

After all, when you think about it: things like domain events can be done without messaging; just replace the message classes with the interface members and replace the handlers with the implementation of the interface that will be introduced into your BC.

These handlers then invoke commands on other BCs; they look like glue that connect different BCs to each other (I think workflows / saga about standing up, etc.).

This may be an example handler:

 public class WorkFlow : IPublishEvents { public void SomethingHappened(Guid SomeId,string SomeName) { AnotherBC.DoSomething(SomeId,SomeName); } } 

This is a simple approach that does not require much effort, and I have used it with great success. If you want to switch to full-blown messaging later, this should be easy to do.

To answer your questions about the user interface:

I think you are too hard on this.

As long as my domain (or can be easily) separated from your user interface, you can easily start with a single user interface project and then split it up for a minute when you start to experience pain somewhere. However, if you split the code, you must split it into BC, so the project structure is consistent.

I find creating a user interface in such a way as to be the most efficient way for me ...

Answer 3

The feeling I get from these questions can be summarized as follows: "What is a reasonable approach to BC boundaries in terms of code artifact and how to create a user interface that executes both requests and commands of several BC?" It depends...

Another approach not yet mentioned may be to treat the UI as a separate context. I doubt this is a very popular POV, but it can be useful from time to time. The user interface can dictate what it needs, for example, its own interfaces and data structures, and each BC implements the corresponding interfaces (making an internal translation). The disadvantage is an additional translation, but again this only makes sense when there is sufficient value to receive. The point is to simplify the work on the user interface side and not worry about how and where the data comes from, or how the changes affect each BC. All this can be processed behind a simple facade. There are several places that this facade could sit (on the client or on the server). Don't be fooled, although the “complexity” has just moved behind another layer. Coordination and hard work remains to be done.

Alternatively, you can also see what I call the "alignment" of the user interface with use cases opened by BC. As Tom noted, this task may require workflows or saga implementations to achieve this. A survey of consistency requirements (when does this other BC need to know about this information?) May provide a new insight into how BCs interact. You see, the user interface is a very useful feedback loop. If it does not match the use case for BC, perhaps something is wrong with the use case, or maybe something is wrong with how it was developed in the user interface, or maybe we just discovered a different use case. This is why UI mockups make such a great discussion tool. They offer an EXTRA view of the same problem / solution. Additionally, as in "this is not the only visualization that you should use in conversations with a domain expert." UX requirements are also requirements. They must be serviced.

Personally, I find that when I discuss the user interface, I am in a different hat than when I discuss the pure functionality (you know, everything that does not require a user interface to explain what the application does / does), I could switch hats during the same conversation to find out about inconsistencies.