{"id":2210,"date":"2018-08-14T22:42:14","date_gmt":"2018-08-14T21:42:14","guid":{"rendered":"https:\/\/www.entropywins.wtf\/blog\/?p=2210"},"modified":"2020-02-12T00:23:21","modified_gmt":"2020-02-11T23:23:21","slug":"clean-architecture-bounded-contexts","status":"publish","type":"post","link":"https:\/\/www.entropywins.wtf\/blog\/2018\/08\/14\/clean-architecture-bounded-contexts\/","title":{"rendered":"Clean Architecture + Bounded Contexts"},"content":{"rendered":"

In this follow-up to Implementing the Clean Architecture<\/a> I introduce you to a combination of The Clean Architecture and the strategic DDD pattern known as Bounded Contexts.<\/p>\n

At Wikimedia Deutschland<\/a> we use this combination of The Clean Architecture and Bounded Contexts<\/a> for our fundraising applications. In this post I describe the structure we have and the architectural rules we follow in the abstract. For the story on how we got to this point and a more concrete description, see my post Bounded Contexts in the Wikimedia Fundraising Software<\/a>. In that post and at the end of this one I link you to a real-world codebase that follows the abstract rules described in this post.<\/p>\n

If you are not yet familiar with The Clean Architecture, please first read Implementing the Clean Architecture<\/a>.<\/p>\n

Clean Architecture + Bounded Contexts<\/h2>\n

Diagram by Jeroen De Dauw, Charlie Kritschmar, Jan Dittrich and Hanna Petruschat. Click image to enlarge
\n<\/em><\/small><\/p>\n

\"Diagram<\/a><\/p>\n

In the top layer of the diagram we have applications. These can be web applications, they can be console applications, they can be monoliths, they can be microservices, etc. Each application has presentation code which in bigger applications tends to reside in a decoupled presentation layer using patterns such as presenters. All applications also somehow construct the dependency graph they need, perhaps using a Dependency Injection Container or set of factories. Often this involves reading configuration from somewhere. The applications contain ALL framework binding, hence they are the place where you will find the Controllers if you are using a typical web framework.<\/p>\n

Since the applications are in the top layer, and dependencies can only go down, no code outside of the applications is allowed to depend on code in the applications. That means there is 0 binding to mechanisms such as frameworks and presentation code outside of the applications.<\/p>\n

In the second layer we have the Bounded Contexts. Ideally one Bounded Context per subdomain. At the core of each BC we have the Domain Model and Domain Services, containing the business logic part of the subdomain. Dependencies can only point inwards, so the Domain model which is at the center cannot depend on anything more to the outside. Around the Domain Model are the Domain Services. These include interfaces for persistence services such as Repositories. The UseCases form the final ring. They can use both the Domain Model and the Domain Services. They also form a boundary around the two, meaning that no code outside of the Bounded Context is allowed to talk to the Domain Model or Domain Services.<\/p>\n

The Bounded Contexts include their own Persistence Layer. The Persistence Layer can use a relational database, files on the file system, a remote web API, a combination of these, etc. It has implementations of domain services such as Repositories which are used by the UseCases. These implementations are the only thing that is allowed to talk to and know about the low-level aspects of the Persistence Layer. The only things that can use these service implementations are other Domain Services and the UseCases.<\/p>\n

The UseCases, including\u00a0their Request Models and Response Models, form the public interface of the Bounded Context. This means that there is 0 binding to the persistence mechanisms outside of the Bounded Context. It also means that the code responsible for the domain logic cannot be directly accessed elsewhere, such as in the presentation layer of an application.<\/p>\n

The applications and Bounded Contexts contain all the domain specific code. This code can make use of libraries and of course the runtime (ie PHP) itself.<\/p>\n

As examples of Bounded Contexts following this approach, see the Donation Context<\/a> and Membership Context<\/a>. For an application following this architecture, see the FundraisingFrontend<\/a>, which uses both the Donation Context and Membership Context. Both these contexts are also used by another application the code of which sadly enough is not currently public. You can also read the stories of how we rewrote the FundraisingFontend to use the Clean Architecture<\/a> and how we refactored towards Bounded Contexts<\/a>.<\/p>\n

Further reading<\/h3>\n

Sign up below to receive news on my upcoming Clean Architecture book, including a discount:<\/p>\n

\n
\n
\n
<\/div>\n
\n
<\/div>\n
<\/div>\n<\/div>\n
<\/div>\n
<\/div>\n<\/div>\n<\/form>\n<\/div>\n

If you are not yet familiar with Bounded Contexts or how to design them well, I recommend reading Domain-Driven Design Distilled<\/a>.<\/p>\n

\n

Blogged: Clean Architecture + Bounded Contexts https:\/\/t.co\/r30eiw4OP4<\/a> #CleanCode<\/a> #CleanArchitecture<\/a> #DDDesign<\/a><\/p>\n

\u2014 @JeroenDeDauw August 16, 2018<\/a><\/p><\/blockquote>\n