Wrox Programmer Forums
| Search | Today's Posts | Mark Forums Read
BOOK: Patterns, Principles and Practices of Domain-Driven Design
This is the forum to discuss the Wrox book Patterns, Principles and Practices of Domain-Driven Design by Scott Millett; ISBN: 978-1-118-71470-6
Welcome to the p2p.wrox.com Forums.

You are currently viewing the BOOK: Patterns, Principles and Practices of Domain-Driven Design section of the Wrox Programmer to Programmer discussions. This is a community of software programmers and website developers including Wrox book authors and readers. New member registration was closed in 2019. New posts were shut off and the site was archived into this static format as of October 1, 2020. If you require technical support for a Wrox book please contact http://hub.wiley.com
  #1 (permalink)  
Old June 19th, 2015, 11:12 AM
Registered User
Points: 17, Level: 1
Points: 17, Level: 1 Points: 17, Level: 1 Points: 17, Level: 1
Activity: 0%
Activity: 0% Activity: 0% Activity: 0%
 
Join Date: Jun 2015
Posts: 4
Thanks: 2
Thanked 0 Times in 0 Posts
Default Bounded contexts, business components, components

Hi,

In chapter 11, it mentions about how to decompose bounded contexts into business components and how to decompose business components into components, but I still don't have a clear ideas of how to differentiate among these terms.

From the example in the book (Shipping bounded context, Priority and Standard business components, arrange and cancel components), it seems like components are use cases (arrange shipping, cancel shipping)? But it also mentions components are unit of deployment, so does that mean each use case should be in its own project/dll for deployment?

Also I think in some cases, there will be some common logic that can be shared among priority shipping and standard shipping (e.g. some common rule to calculate basic shipping fee), but it says business components should not have any dependencies, how does it handle the common logic?

Many thanks
  #2 (permalink)  
Old June 22nd, 2015, 05:47 AM
Wrox Author
Points: 237, Level: 4
Points: 237, Level: 4 Points: 237, Level: 4 Points: 237, Level: 4
Activity: 0%
Activity: 0% Activity: 0% Activity: 0%
 
Join Date: May 2015
Posts: 59
Thanks: 1
Thanked 5 Times in 5 Posts
Default

Hi,

Actually you are vary close. Bounded Contexts and Business Components are conceptual. Bounded Contexts are containers for Business Components, and Business Components are containers for components. It's only the components themselves that have physical artefacts like code and configuration.

Generally, you should look to make each component have its own codebase, and share no code with other components. Very close in nature to microservices, if not exactly the same, the idea is to keep components independent of each other so that they can evolve independently. You want to be careful of making changes to one and breaking another.

However, if you feel that two components inside different Business Components really do share common logic, you really have two choices; you can explore the domain to work out whether they really are distinct Business Components. Or, you can duplicate the logic. What we see most often is that logic starts out being very similar, but then each Business Component wants it to change for different reasons.

I use the word generally because we don't believe in hard and fast rules. As long as you know that adding dependencies between components can cause friction, it is up to you to acknowledge that and decide in your particular scenario it is better to avoid the guideline.

Basically, if you understand why the guidelines exist, and think you can benefit by ignoring the guidelines, then go for it. However, if you are unsure, it helps to get a number of different opinions and make a team decision.

To me, this is really a classic example of where DDD shines. You think there is a technical problem - code reuse, but really it is a domain issue. You need to work with people to really understand what the Business Components are, and if these two concepts (the shared pricing logic) really are the same, or whether they just look the same. For example, ask domain experts if the standard pricing could ever be changed for different types of customer. They might even tell you: "yes we would love to do that, but the old system wouldn't let us". I cannot tell you how many times I have heard comments like that from business stakeholders.

Is that helpful? If not please keep asking away.
The Following User Says Thank You to nick_t For This Useful Post:
hpcsc (June 22nd, 2015)
  #3 (permalink)  
Old June 22nd, 2015, 10:27 AM
Registered User
Points: 17, Level: 1
Points: 17, Level: 1 Points: 17, Level: 1 Points: 17, Level: 1
Activity: 0%
Activity: 0% Activity: 0% Activity: 0%
 
Join Date: Jun 2015
Posts: 4
Thanks: 2
Thanked 0 Times in 0 Posts
Default

Thanks for your reply
Your explanation on the shared logic helps me clear the doubt
However for the bounded context, business component and component, I still have some wondering:

- As I understand from your explanation, each component should have its own codebase (by that I think you mean its own project and the example in the book also follows that guideline), but for large project, it's not uncommon to have several hundreds use cases (and therefore several hundreds components - approximately), is it becoming too many components to manage? I'm not entirely familiar with microarchitecture though, just starting looking into it.

Or it also requires our own judgement, case by case also? .i.e. for components that are likely to scale together, they are grouped into a common codebase/deployment unit
  #4 (permalink)  
Old June 22nd, 2015, 12:20 PM
Wrox Author
Points: 237, Level: 4
Points: 237, Level: 4 Points: 237, Level: 4 Points: 237, Level: 4
Activity: 0%
Activity: 0% Activity: 0% Activity: 0%
 
Join Date: May 2015
Posts: 59
Thanks: 1
Thanked 5 Times in 5 Posts
Smile

Hi,

Thanks for your questions.

If you're building a large complex distributed system, we are suggesting in the book that each component could be a single sub-system that runs independently - it is deployed on its own and it shares no code with any other component.

However, in some systems, you may want to start out with a single modular codebase where everything runs in process and then start to distribute it.

Fundamentally, you need to think carefully about coupling. If you share code between multiple teams, those teams will slow each other down. One team may make a change that breaks another team's code. By completely removing dependencies between teams, each team can work full steam ahead without being distracted by other teams except for when it is really necessary.

For me, the most important consideration is getting bounded contexts right. If everything inside a bounded context is owned by a single team, it's easier for them to restructure and refactor their components. In my career, I've always found it takes so much longer to get things done when you have to coordinate multiple teams - each of which has its own priorities, backlog etc

Reassuringly, your example of a large enterprise system with hundreds of use cases is not uncommon. If you cohesively group those use cases into Bounded Contexts, and each team owns a Bounded Context, each team has a manageable number of components that they could deploy independently if they wanted to.

I hope that helps, but please keep asking if you have more questions or anything is unclear. I don't mind replying and I'm happy to have a skype chat sometime if you prefer.

Last edited by nick_t; June 22nd, 2015 at 12:23 PM..
The Following User Says Thank You to nick_t For This Useful Post:
hpcsc (June 22nd, 2015)
  #5 (permalink)  
Old June 22nd, 2015, 07:39 PM
Registered User
Points: 17, Level: 1
Points: 17, Level: 1 Points: 17, Level: 1 Points: 17, Level: 1
Activity: 0%
Activity: 0% Activity: 0% Activity: 0%
 
Join Date: Jun 2015
Posts: 4
Thanks: 2
Thanked 0 Times in 0 Posts
Default

Hi,

That answers my question and helps me a lot

Many thanks


Similar Threads
Thread Thread Starter Forum Replies Last Post
Developing Components. rupen ASP.NET 1.x and 2.0 Application Design 0 March 23rd, 2008 07:08 AM
COM+ components registration ajindal General .NET 1 September 1st, 2006 03:31 AM
Accesing COM+ components from c# txerra General .NET 2 June 24th, 2005 05:23 AM
How to write the COM components in C# stonewall C# 2 June 22nd, 2005 08:19 PM
Accesing Com+ components from c# txerra C# 1 June 22nd, 2005 06:10 AM





Powered by vBulletin®
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
Copyright (c) 2020 John Wiley & Sons, Inc.