Picon

Bounded Context with modules in .NET



As I understand, a Bounded Context can contain multiple modules.


Let us take a Product Catalog Bounded Context. This Product Catalog BC can contain modules like CatalogManagement, ProductManagement.


When it is implemented in .net, the CatalogManagement and ProductManagement can be implemented as assemblies. Since they are part of the same Bounded Context, should they be implemented in the same namespace to draw the boundary?


This is my understanding of Bounded Context. The core domain and sub domain are discussed at the problem space while Bounded Conte xt and Module are discussed at the solution space where there are implementations. I don't know how the Bounded Context and Modules are implemented in .NET.


Thanks.



__._,_.___
Posted by: varghese.pallathu <at> yahoo.com



__,_._,___
Picon

Transactionally Consistency in DDD



I'm stuck at a quote from  Vaughn Vernon in his IDDD book. Here it goes:


"An Aggregate is composed of either a single Entity (5) or a cluster of Entities and Value Objects (6) that must remain transactionally consistent throughout the Aggregate’s lifetime." - Implementing DDD by  Vaughn Vernon


I'm trying to understand "transactionally consistent" that is mentioned here. Is it the behavior of the repository that makes sure the aggregate should be consistent when it is read or committed from the database.


Or it the consistency of the aggregate when it is operated in memory and goes through state changes and shows consistent behavior.




__._,_.___
Posted by: varghese.pallathu <at> yahoo.com



__,_._,___
Picon

Aggregate or not?



I have an example to understand the aggregate design.


The business language goes this way. I own ten restaurants. I will buy furniture from a furniture store and use them in any of the five restaurants. I will hold, assign, remove or swap furniture in the five restaurants. When I buy a new furniture, I will ask the furniture store to hold the furniture in their warehouse until I decide which restaurant I should use that. Sometimes, I don't have time to decide which furniture should go which restaurant. I will hire an interior designer to look at the furniture on hold in the furniture warehouse to decide where they should be put.


Thinking about the composition, I can have a Restaurant entity  and a Furniture entity.


class Restaurant

{

private List<Furniture> Furnitures;


void BringSome(List<Furniture> furnitures);

void RemoveA(Furniture furniture);

}


class Furniture

{

Restaurant Restaurant;


void AssignMeTo(Restaurant restaurant);

void RemoveFrom(Restaurant restaurant)

}an>


The Restaurant is a good candidate for aggregate root. It contain the Furniture.


Can the Furniture be an aggregate root too? My interior designer need to have access to the Furniture which are on hold (still in the Furniture warehouse) and not assigned to any restaurant, so a furniture can exist without it's root, but it will become part of the root only after it is assigned. I'm comparing this to Order.OrderLineItems relation. An order line item can't exist without an order. But in my example, a furniture can exist without a restaurant.


Appreciate your thoughts.


n>






__._,_.___
Posted by: varghese.pallathu <at> yahoo.com



__,_._,___
Picon

Re: Massive stored proc data base operation to DDD



Hi Varghese,

If your behaviours cannot be defined as simple methods (or functions), I think you should simply reconsider your model.
Remember : your domain model should be designed to enable the creation of value (a.k.a. the implementation of methods or functions) of your application. It is using domain vocabulary (ubuquitous language) but its design and structure should be made to support the domain scenarios. In other words, you are not building a realistic model of the world but rather a model for a particular purpose (i.e. to support domain scenarios): modelling is driven by those scenarios.

In your particular case, you want to create two clusters of products ("Vegetable Products" and "Non Vegetable Products") from an "Unclassified Product Sets" (I think we have here three nice aggregate roots). "Unclassified Product Sets" might have a method "classify" (probably the entry point of your scenario) which takes a set of "Companies" (probably Value Objects) as a "vegetable Vendors" input argument, and a tuple of "Vegetable Products" and "Non Vegetable Products" as output argument.

It seems to me that this "classify" method can perfectly be implemented (directly on the class or as an "Unclassified Product Set Repository" method) in a stored proc and be perfectly OO (or FP if you prefer). Moreover this is definitely not an anemic model at all !

The problem you face comes from the fact you expressed it with the right words, but in the wrong Bounded Context.

Regards,

Greg Weinbach



__._,_.___
Posted by: =?UTF-8?Q?Gr=C3=A9gory_Weinbach?= <gweinbach <at> gmail.com>



__,_._,___
Picon

Massive stored proc data base operation to DDD



Lets take an example of a product classification. All the products needs to be classified as vegetable or not. This is a command which should take some time to complete because there are millions of products. This is a B2B scenario, so the agents do this operation quite often like few times every day. This is a UPDATE operation not a read operation. The business logic is, the product can be classified as vegetable if that product is from company A, B & C. If the product is not from those companies they are not vegetables. There are millions of products in the database with it's vendor. Approaching this from a data perspective, this can be done in a stored procedure with few lines of code. The operation may take only few seconds even if it is done synchronize.


Now let me approach this from a DDD perspective. As I understand, the DDD goes against the idea of putting the logic in the stored procedure. The logic can be put as a behavior on product which can self classify based on who is the source, or the aggregate root can do that job. To do this, all the million products need to be read into memory from the database, process and then save it back to the database through the repository (whether it is SQL, Document based, mySql or whatever).

 

The problem here is the large amount of memory this operation needs when done using the DDD approach. If the operation is done in chucks like 50,000 the repository has to first figure out how may products needs to be classified and&nbs p;the domain has to plan the long running operation in chunks. Surely, this approach is going to take more time and a bad user experience for the user who has to wait more time than a process than a stored procedure takes.


What is the reasonable approach to DDD when it comes to long running massive data processes? Is the delay expected, so the app has to inform the user that the classification is going to take time like 5 minutes or so and will let the user know when that is complete? And should not use stored procedure to have the classification logic, but have the business logic as part of the domain.


You can think about the classification business logic which can change in the future. In this example, it is b ased on the vendor who provides the product. That can change to country. For example, all the products come from Country A will be wine. There is a greater flexibility with having this logic as part of the domain. But what worries me is the large amount of memory this operation has to take.


Appreciate feedback from DDD gurus.





__._,_.___
Posted by: varghese.pallathu <at> yahoo.com



__,_._,___
Picon

Guidelines to decide when a domain role needs to be explicitly modelled



I looking for some guidelines as to when one must explicitly model a role in the domain model.

I will explain my current stance with the help of an example here.

Say we are building a health care system, and the business requirement states

"That only doctors with 3+ years of experience and certain qualifications can perform surgeries"

In this case it is evident that the act of doing a surgery can only be performed by a person playing the role of a doctor and the doctor needs to meet certain prerequisites to perform the action

docter.performSurgery()

So basically all doctors are not the say

This method will probably check if the preconditions are met, else i might use a specification object.

So in the above cases, I will model the role explicitly.

Now lets consider the alternate scenario.

Only a admin can approve of a funds transfer

In the above case I do not find any need to model this role in domain, as their are no rules distinguishing one admin from another in my domain.

Any person/userlogin with the permission of admin can perform this action, I would rather design this into my security infrastructure and ensure that the

approveTransfer() method invoked on the application layer is invoked only if the currently logged in user has the ADMIN permission.

So the "domain model" by which i mean classes like the Account class and unaware of this rule, this is codified in the application layer either via AOP or probably the AccountService class or the like.

What do the wise men have to say about this ? :)




__._,_.___
Posted by: sudarshan89 <at> yahoo.com



__,_._,___
Picon

Large domain, small team: how many contexts?



Hi all,


For the last year, I've been part of a small team of 2 developers working on a large project that is usually tackled by much larger teams. We are trying to drive the design of our domain model using DDD principles. We are succeeding to a certain extent, but we are struggling with the definition and separation of bounded contexts. I would like to request your advice on this problem.


To sum up the purpose of our application, we could say that it allows organizations to plan, track and report on collaborative projects. The main features are as follows:

  • user management
  • organization management (internal org chart, employees)
  • relationship management (customer / vendor accounts, contacts)
  • ratecard management (services, pricing models)
  • budgeting
  • project tracking (task assignment, progress and completion, etc.)
  • procurement (requests for proposal, business proposals, purchase orders)
  • accounting (invoices, receivables and payables, payments, collection, etc.)
  • reporting (budgeted vs invoiced, employee productivity, profit margins, etc.)

There is a strong requirement for traceability between entities throughout the process: one should be able to reconstitute the path from an original budgeted line item up to an invoiced line item, thereby allowing an organization to produce high-quality reports.


Reading the literature (both the Evans and Vernon books), I gather that bounded contexts serve multiple purposes: defining a linguistic barrier within which concepts are clear and unambiguous, allowing teams to work in parallel with minimal friction, and reducing coupling between different pa rts of the model. I also gather that an application may be divided in bounded contexts of varying granularity, ranging from a single coarse bounded context for the whole application down to several fine bounded contexts, one per feature. Given the application we're working on, and the current size of our team, it's unclear where in that granularity spectrum we should be standing.


There is a case to be made for having a single bounded context:

  • Our team is small, we communicate easily and we have a low integration cost.
  • We have elaborated a clear vocabulary within which concepts are clear(ish) and ambiguities are few and far between.
  • Integration between features is a selling point for this application, and so some entities are to be used by several features (e.g. a ratecard element can be used in a budget, a project timesheet and an invoice)
  • No duplication. An organization is an organization is an organization.

There is also a case to be made for having several bounded contexts:

  • Although our team is small today, we hope to grow in the future. Both communication and integration will become harder. Bounded context s would help us grow more easily.
  • The application will assuredly grow, and so will our vocabulary. Ambiguities and polysemes will surely appear. Bounded contexts would help us better contain and demarcate models.
  • Already, some concepts are used differently depending on the feature they live in.
    • For example: a ratecard element is used as an entity within the ratecard management feature (allowing for change tracking and an approval process), but it is used as a value in other consuming features (where it is considered to be stable, valid and approved).
    • Another example: an organization is responsible for hiring an employee within the organization management feature, while it is responsible for launching a project in the project tracking feature. Having separate implementations of the organization concept would allow for classes with clearer responsibilities (instead of having a God-like organization responsible for creating everything).
  • Already, changes to a central concept (customer / vendor account) has rippled throughout the model because of the high coupling to it.

As an experiment, we have attempted to separate the application in a few contexts. We saw some advantages: lower coupling between features and clearer responsibilities for classes. But we also saw some drawbacks: *lots* of duplicated code (n implementations of Organization, n implementations of Customer, etc.) and *lots* of translation code between contexts, which leads us to questions such as "why didn't I just use the original entity instead?" It also brought some questions regarding the visibility of concepts, such as "when defining the vendors to invite to a RFP, should I consult the relationship management context or the procurement context? and so will I need to add similar API endpoints to retrieve vendors in every consuming context?"


Needless to say, these questions are driving us mad and leading to discussio ns that, while interesting, ultimately leave us feeling like a) we don't understand anything, and b) we're losing our time on over-architecture.


So... if you're not exhausted from reading this, what advice could you give its very confused author? :)


Thank you very much in advance!




__._,_.___
Posted by: gbilodeau <at> yahoo.com



__,_._,___
Picon

composing multiple bounded contexts in a single user interface



We are developing a system which is composed of multiple bounded contexts, there are user interfaces where the information displayed needs to be rendered from multiple bounded contexts.

A classic example of such an interface is the Amazon.com ordering page. Where we see about about the product (product BC), inventory available (Inventory BC), prices and so on

My question, in such scenarios in which bounded context would the user interface live in ?, I get how we can pull data from multiple BC's to form the page, but are their in guidelines as to where the page itself will reside ?

Similar questions here and here, they deal with how to get information from the multiple BC's, but they do not address in which BC the user interface itself will live in ?

Any guidelines on that ? With an example would be great...




__._,_.___
Posted by: sudarshan89 <at> yahoo.com



__,_._,___
Picon

Framework for managing domain events



I am trying to learn how to implement domain events and use them to integrate various bounded contexts. I've read Vaughn Vernon's Implementing Domain-Driven Design, but as the book aim was to introduce the concepts, so most of the domain events generation and handling was done manually.


In the Java world is there a framework(s) that can be used to handle events generation, publishing, consumption, error handling,,,,etc?


I understand that I might be mixing several concepts here. For example maybe the events generation can be done by one framework and managed by another framework.


Can someone please recommend the current best tools to automate the management of domain events from end-to-end in Java?


PS: I'm not looking for anything related to Event Sourcing.



__._,_.___
Posted by: songoko20000 <at> yahoo.com



__,_._,___
Picon

Are web applications complex enough to domain-driven design?



After much reading and some attempts to implement DDD, I think I understand what people mean when they say the concept was developed for complex domains.

I usually develop web applications for small and medium businesses, usually the interactions are just CRUD application and tables in HTML, which goes beyond this are some validations before inserting the data into a database.

I was reading about CQRS on Martin Fowler's website and a phrase caught my attention: "CQRS is suited to complex domains, the kind that Also benefit from Domain-Driven Design.".

So my question would be how to analyze the complexity of the software?
When applying DDD worth?
Worth applying DDD in software for small and medium complexity?

Thank you!




__._,_.___
Posted by: lc <at> leocavalcante.com



__,_._,___
Picon

Introducing VBooky.com - Help for popularizing and any support!



Dear All,
  It's been sometime since I have got in touch with many. Here's a few updates on what I have been upto.

For the past 6 months or so, I have been working on starting up a company - Fyno Pvt. Ltd. and bringing up a product in the domain of Spa, Salon and Wellness. Now it's been in operation (beta) for the past 1 month or so.

Online Product - www.vbooky.com 
What it is - It is a online marketplace and platform for Salon, Spa & Wellness Industry, India
What You can do - You book your salon , spa services online like your next hair cut or pedicure or relax with a deeply soothing Swedish Massage .. & many more.

Brief Intro Video 

It is still in Beta even as we try to streamline the operations and few technical issues. Any feedback is most welcome :-) 

I need help and support in below areas. Any help is most welcome :-)

1) Popularize the website - Please register, login & book. Please invite at least 5 friends and make a booking. As of now bookings are only for Bangalore locations. 

2) Like Us on Facebook & invite your friends too

3) Spa and Salon tieups - We are working to get as many salons and spas online soon. If you can provide any more, if not not yet listed & you want them, please send the details .

4) Any good publicity - media, online, blogs & introductions & ideas - most welcome. 


​Sorry, if this mail has reached unintended inbox. My sincere apology. I have tried to remove irrelevant email id from my contact list.​

--
Thanks and Regards,
Ingudam Manoranjan
​​


__._,_.___
Posted by: Ingudam Manoranjan <ingudam <at> gmail.com>



__,_._,___

Gmane