Implementing Domain-Driven Design (Study Group) Chapter 3 - Context Maps

1. Chapter 3 - Context Maps Speaker: Eason Kuo Date: 2019/04/10 @ Taiwan iDDD Study Group Why Context Maps Are So Essential

2. Define business domain to Problem Space, distinguish each business subdomain By ubiquitous language, find the boundaries of each subdomain and distinguish the Bounded Context Recap Bounded Context © 2019, Eason Kuo, Taiwan iDDD Study Group

3. Define business domain to Problem Space, distinguish each business subdomain By ubiquitous language, find the boundaries of each subdomain and distinguish the Bounded Context Recap Bounded Context © 2019, Eason Kuo, Taiwan iDDD Study Group Okay Everything seems great, right?

7. Issue 1 : More Complex Scenario, More Unclearly Bounded Context

9. Issue 3: Large team size or multiple development teams

15. Context Maps Description Context Maps could reflect the collaborative or even organizational teams relationships between different Bounded Contexts in your systems. What is Context Maps? © 2019, Eason Kuo, Taiwan iDDD Study Group

16. A simple Context Maps draws the U (Upstream) and D (Downstream) Shows Bounded Contexts integration relationship. Upstream and Downstream What is Context Maps? © 2019, Eason Kuo, Taiwan iDDD Study Group

17. Focusing on what’s happening between different bounded contexts. Inter-communication with teams. Discover relationship / influence from Bounded Contexts mapping to your teams or others partners. The helping from Context Maps What is Context Maps? © 2019, Eason Kuo, Taiwan iDDD Study Group

19. • A Context Map captures the existing terrain and landscape will change as your current project progresses, you can update it. • we could to include other items such as Modules, Aggregates or team allocation to assist us. • All Information, Context Maps can put into reference document / wiki if it has value. The Benefit for Drawing Context Maps The Benefit for Drawing Context Maps © 2019, Eason Kuo, Taiwan iDDD Study Group

20. • If detail too much, it’s helpless and fewer people want to use the Map, assist team to communication is important. • It can providing views of the enterprise not otherwise available • Could find the some bottleneck like integration, management . The Benefit for Drawing Context Maps The Benefit for Drawing Context Maps © 2019, Eason Kuo, Taiwan iDDD Study Group

24. Discovering potentially crisis

27. • Different teams / separate bounded context crossover in terms of domain concepts and logic. • With an explicit boundary subset of the domain model that the teams agree to share. • shouldn’t be changed without consultation with the other team • At this case, recommended that they do so as a partnership. Not distinguish U/D Relationship 1. Shared Kernel Relationship Patterns for Context Maps © 2019, Eason Kuo, Taiwan iDDD Study Group

28. • When teams in 2 Contexts will succeed or fail together • coordinated planning of development and joint management of integration. • cooperate on the evolution of their interfaces to accommodate the development needs of both systems. Not distinguish U/D Relationship 2. Partnership Relationship Patterns for Context Maps © 2019, Eason Kuo, Taiwan iDDD Study Group

29. • teams are in an upstream- downstream relationship. • Upstream teams could interdependently developing feature. • Downstream teams will be influence from upstream. 3. Customer – Supplier Relationship Patterns for Context Maps © 2019, Eason Kuo, Taiwan iDDD Study Group

30. • Also upstream-downstream relationship. • Upstream team has no motivation to provide for the downstream team’s needs. • Downstream is helpless. 4. Conformist Relationship Patterns for Context Maps © 2019, Eason Kuo, Taiwan iDDD Study Group

31. • If 2 sets of functionality have no significant relationship • cloud be completely cut loose from each other. • Declare bounded context have no connection to others at all. • Enable to find simple, specialized solutions within the scope 5. Separate Way Relationship Patterns for Context Maps © 2019, Eason Kuo, Taiwan iDDD Study Group

33. • Happens on Shared Kernel, Partnership, Customer-Supplier can not implement. • Downstream build a translation layer (Adapter) to protect inner domain model. • The ACL also be a interface layer to cooperate with external system, decrease changed. 7. Anticorruption Layer (ACL) Relationship Patterns for Context Maps © 2019, Eason Kuo, Taiwan iDDD Study Group

34. • Define a protocol that gives access to your subsystem as a set of services • Open the protocol so that all who need to integrate with you can use it. • Other systems or components that communicate with OHS will use transformation layer for translating our model into terms of their own, similar to the ACL. 8. Open Host Service (OHS) Relationship Patterns for Context Maps © 2019, Eason Kuo, Taiwan iDDD Study Group

35. • The translation between the models of two Bounded Contexts requires a common language • Use a well-documented shared language that can express the necessary domain information, translating as necessary into and out of that language. • Publish Languages often combined with Open Host Service 9. Public Language (PL) Relationship Patterns for Context Maps © 2019, Eason Kuo, Taiwan iDDD Study Group

39. Example – Insurance Company 20 mins Practice © 2019, Eason Kuo, Taiwan iDDD Study Group P M s I u M A -A D D r a W r - CDA B 5 5 D t W t s - CDA BC Io M W S c W y - CDA B 3 > 3 B 5 5 D t W x M4 6 b W d k f 1A> 5 5 D t W t I m -A DB5 DC 1A> C 2 C 5 5 D A D D n M . 6D -A>> D A -A D D I . 6D -A>> D A g W I m -A DB5 DC 1A> C e g s I ( 2 C 5 5 D t W 1A> 5 5 D -A D D vy I R -A DB5 DC 1A> C ) 1B D -A D D l t W x S W 1 I t l I f I . 6 D 1A> C - CDA BC I i

40. © 2019, Eason Kuo, Taiwan iDDD Study Group a n B 9 2 2 9 it C Ph od e M 9 2 2 9 pS 9 1 x m Dl ru pP U w s 9 1 K 0 1 9 1 . 61 9 -1 Rx / 1 2 6 2. Partnerships 3. Customer-Supplier 4. Conformist 5. Separate Way 6. Big Ball of Mud 7. ACL 8. OHS 9. PL . 61 9 -1 Example – Insurance Company 20 mins Practice

43. • CollabOviation - social collaboration suite product. • enables register to publish content. • Using forums, shared calendars, blogs, wikis • IdOvation - A reusable identity & access management model. • provides secure role-based access management for registered users • ProjectOvation - An agile project management product. • create project management assets • analysis and design artifacts, and track progress Recap Three Bounded Context Product Mapping the IDDD Three Bounded Context - SaaSOvation © 2019, Eason Kuo, Taiwan iDDD Study Group

44. • Unclear part for user permission in Collaboration Context • Analyze and split unclear part (user permission) from Collaboration Context • Put user permission part to Identity & Access Context Collaboration Context Mapping Example Mapping the IDDD Three Bounded Context - SaaSOvation © 2019, Eason Kuo, Taiwan iDDD Study Group

46. • OHS - Implementing like API using REST, RPC, SOAP or Message exchange. • Even old way like Files, database is OHS (not recommend) • PL – represent Domain concept. • Like XML/ JSON • if you want to use User Interface, also HTML is Ok. • Can be used in Event-Driven Architecture by Domain Event to deliver message for subscriber. • ACL – Define Domain Service or Repository to request OHS and return PL • Build a translation interface like Adapter and translate to Value Object OHS/PL and ACL for Implementing. Code Implementing for Context Maps Representation © 2019, Eason Kuo, Taiwan iDDD Study Group

47. • UserRoleAdater and CollaboratorTranslator representation and translate it, creating the appropriate Value Object instance – Moderator. • CollaboratorService is Domain Service • But why creating Value Object ? Collaboration Context with Identity & Access Context Code Implementing for Context Maps Representation © 2019, Eason Kuo, Taiwan iDDD Study Group

48. • In order to achieve greater degree of autonomy, make dependent state is already in place in our local system. • In DDD, not use Cache. DDD create local domain objects translated from the foreign model, maintaining only the minimal amount of state needed by the local model (p795 - Integrate with Minimalism) • To get the state in the first place we may need to make limited. Autonomy - Value Object for minimal amount of state Code Implementing for Context Maps Representation © 2019, Eason Kuo, Taiwan iDDD Study Group

50. • In Agile PM Context, each Domain Service map to its Translator, and use Translator to create Value Object to achieve minimal mount of state data. • Actually there is not one single CollaborationAdapter. It is just a placeholder for the several needed, it may changes by times. Agile PM Context with Collaboration Context Code Implementing for Context Maps Representation © 2019, Eason Kuo, Taiwan iDDD Study Group

51. • In Agile PM Context, a feature is “when system creates the Product with a Forum and Discussion. ” • Agile PM Context needs objects that don’t exist yet and won’t exist until it requests them, it is Potential obstacle to autonomy. • Because we depend on the availability of the Collaboration Context in order to create resources remotely. Dependent on other Context to do Action issue Code Implementing for Context Maps Representation © 2019, Eason Kuo, Taiwan iDDD Study Group

52. • Using Standard Type Value Object be implement States and default state, to get default Value Object. • If The state is READY, Then it’s can access. • In here, use Enum to list different state. Solution Method – Standard Type for Value Object Code Implementing for Context Maps Representation © 2019, Eason Kuo, Taiwan iDDD Study Group

55. Context Maps could reflect the collaborative or even organizational teams relationships between different Bounded Contexts in your systems. Drawing your Context Map using 9 Relationship Patterns and changes as your current project progresses. Using ACL or OHS/PL could assist you to translate outer Bounded Context , decrease unnecessary changes and protect your Domain Model in your Bounded Context. Recap for Context Maps (1) © 2019, Eason Kuo, Taiwan iDDD Study Group

56. Try to make your Bounded Context could achieve a greater degree of Autonomy Autonomy - make dependent state is already in place in our local system, maintaining only the minimal amount of state needed by the local model. Using Value Object / Standard Type skill to keep minimal amount of state (More detail : Value Object in Chapter 6 ) Recap for Context Maps (2) © 2019, Eason Kuo, Taiwan iDDD Study Group

Implementing Domain-Driven Design (Study Group) Chapter 3 - Context Maps

Esté a ler uma amostra.

Confira estes a seguir

Implementing Domain-Driven Design (Study Group) Chapter 3 - Context Maps

Mais Conteúdo rRelacionado

Diapositivos para si (20)

Semelhante a Implementing Domain-Driven Design (Study Group) Chapter 3 - Context Maps (20)

Mais de Eason Kuo (17)

Mais recentes (20)