I am not sure if this is the right forum to ask this question.
We are a startup having customers in 4 different locations. Our customers are being served from cloud - hosted in 4 different data centers in different locations. We have a requirement of SOC-2 for the customers of a particular location e.g. customers of USA.
Is it possible to keep the scope of SOC-2 to US data centers? It is hard for us to prepare ourselves for all data center at this stage of the company.
We have confirmed this with our auditors that scope can be limited to one location.
Related
I am new learner in SOA ( Service Oriented Architecture ) I have one question for below scenario:
In a company (Mycompany), Sales Team is there ( which is a technical authority for business capability –here sales is the business capability). That company decided to create 2 products say Mycompany.Photos.com and Mycompany.Grocery.com. For both websites they need sales capability i.e. order acceptance capability.
Hence Sales team has to work for both websites. Because, both website needs sales capability.
Now the question is should sales team create 2 different databases for each websites and 2 different endpoints also ?
for example:
If Sales team initially had one queue "Mycompany.Sales.Endpoint" and it receives CreateOrderCommand. It handles CreateOrderCommand, creates order in sales DB and publishes OrderAcceptedEvent. When they were supporting just one website. If they start supporting both website with same endpoint then how would Sales differentiate weather this order is for Mycompany.Grocery.com or Mycompany.Photos ? Should we split Mycompany.Sales.Endpoint into 2 ? should sales team has to be aware of Photo website orders and Grocery Website orders ?
One answer I can think of is:
Sales team can create 2 different databases each for Mycompany.Grocery.com
and Mycompany.Photos.com
Deploy 2 different Business Components (BC) for each websites.
Sales will have 2 Endpoints say "Mycompany.Grocery.Sales.Endpoint"
for Mycompany.Grocery.com BusinessComponent and "Mycompany.Photos.Sales.Endpoint" for MycompanyPhotos.
Even though they are under same Sales Bounded context, can it have 2 Business
Components (BCs) ? Am I correct, Is this the way we scale sales team will support both products for the sales capability ?
I am sorry for the long message. I could not find any shortcut way to explain this.
I think the better way to think about this situations that you effectively have two companies - one in the grocery business, with all the corresponding capabilities that make that up, and the other in the photo business. Even if the two "companies" happen to share the same incorporation documents, you really shouldn't view this as a single entity.
A service is the technical authority of a business capability.
If you should be able to differentiate between an order from either system, but you can't, you're probably building a 'technical authority' for multiple business capabilities.
Other than that, a service can have many components. Instead of focusing on technical issues, focus on the business issue and see if you can explain that. But a platform like Stackoverflow, with a 1-to-1 ratio on question & answer probably isn't the correct medium for questions like this.
What I'm trying to achieve is to develop an application implementing the DDD approach.
The story might sound silly but it's an actual, real life problem. Believe me.
The business looks as follows:
Let's say a company specializes in manufacturing sweets which are distributed to its own shops for sale.
The craftsman makes different types of candy depending on what is - and what is not - currently at the display at one of the company's shop.
When a basket of one flavour 'disappears' the seller replaces this type of sweet with a different kind from the shops storage cabinet.
Duplicates of flavours at the display shouldn't exist and the display should be populated with as much as the capacity allows or how much the manafacturer can handle to produce.
The sweets are distributed from the manufacturer's lab's storage to the shop's one depending on the demand.
Let's assume each worker has public view access to the display and the storage cabinet. Each worker (user) decides on it's own what to provide. The shops display view will be publicly accessible through the application to a potential client as an information what is currently on sale.
So far I have split the business logic into three separate (sub?)domains which are:
Production
Distribution
Sale
And of course each entity like Sweets, Storage, Craftsman, it's Repository etc. are placed respectively in their domain.
The concerns I approach are:
Is it appropriate that an entity (Sweet) is being passed from one domain to another?
Should a Provider be able to reach the StorageCabinet of one domain and pass it's content to another?
Is my reasoning proper? Correct me if I'm wrong or violating any DDD rules.
Thanks in advance.
The story might sound silly but it's an actual, real life problem.
This is great, actually. In his recent retrospective, one of the things that Greg Young called out is that "shopping cart" models are a really lousy as a teaching tool. He points out briefly that the interesting questions are in the supply chain.
Is it appropriate that an entity (Sweet) is being passed from one domain to another?
No, but a message (DTO) describing an entity's state might be passed from one domain to another.
You want to keep the flexibility to define the entities differently in each domain; that's part of the point of identifying bounded contexts.
Should a Provider be able to reach the StorageCabinet of one domain and pass it's content to another?
Probably not: your domain model isn't the book of record for the storage cabinet. Listen very carefully to Greg's comments on one way commands.
Normally, we restrict access to our website from certain countries at the edge of our network. We are about to deploy our application to Azure and need to block certain countries from accessing it. This is due to U.S. Embargo policies... What is the best way to block certain countries so we meet U.S. laws and regulations?
Thanks,
Mike
One idea is to build a simple proxy that attempts to filter on region. My teammate Ricardo Villalobos co-wrote an MSDN article explaining how someone might do that with node.js, in Azure, filtering against the MaxMind geolocation database. It's probably not an exact fit, as it deals with media stream filtering, but you should be able to use the basic technique and proxy described, as a starting point.
So we may apply the domain driven design for multiple projects but there could be intersection of the same piece of domain model.
In this case, how to apply the domain driven design (use ORM, model first, generating database schema)? Create multiple databases with a lot of same tables? Or how to share data? Use synonyms? What is the possible strategy to resolve the sharing model (including data)?
Any suggestion is welcome. Thanks in advance!
In my previous project we had a lot of discussions regarding having redundant info in several models that have some shared parts.
What we found interesting is that we thought that several projects (not C# proj, but real large development projects) or call it systems very rarely share the exact same perspective on how using the model. We thought that in a larger domain that spans over several application/systems/projects you could spot several core's where you don't want the cores to be duplicated in each application.
It all ended up with a domain that where distributed on several machines. And we had GUID keys to bind them together in database. But since we did this "model first", sub domains looked at each other like infrastructure related services that where reached through Domain events.
Complicated? Not really. Here's an example:
Domain one (Salary review system) - We have a Salary Review statistic system which conduct evaluation on employees salary and how they related to their experience, age and performance. The Core is questionnaire form, work evaluation, questionnaire answers, rating. salary modification advices etc.
Domain two (Employee system) - Here you manage your employee, register new employees, handle rehab, maybe personal development, salary, employee contract, employee benefits etc.
Domain three (Performance management) - Here you handle history of employee experience, goals, achievements, and agreements between boss and employees about personal development, rating and grade of performance.
As you notice the Core of each domain is different but they share some concerns. Depending on deployment, infrastructure and requirement on how tight they should relate/respond to each other - the tech how to solve this could differ.
I Prefer to do this tech independent. We used NServiceBus for synchronizing domain through Domain Events (Udi Dahn's Domain Event Pattern).
For instance, Once we have completed a salary review for an employee and boss should be informed that Joe should get a chance of salary increase with 200 - 500 $ this year.
The method ApplySalaryReview on entity aggregate root Employee do not only save the review result, it also trigger domain event NotifySalaryReviewSubscribers which trigger an eventhandler HandleNotifySalaryReviewSubscribersEvent in Application layer that takes a infrastructure service in ctor. That service puts result in a message queue that all systems that need this info can subscribe on this message.
In our case, it is Domain two (Employee system). The employee system import result and notify employee's boss that he got new info for the upcoming salary talk with this particular employee.
I hope I may have shread some light on one way of doing it. There are so many other ways as well...
You might want to (re-)read the strategic design patterns in the blue book.
I'm the IT Manager at a mid-size manufacturing company. We are getting our feet wet with SharePoint - so far we're got one blog in production use> It's the CEO's.
We have use cases for a couple of list-based "applications" with some simple workflow that will be implemented by one of our developers. We also want to give our users (at least the more tech-savvy ones) the ability to create and work with their own departmental sites.
We're concerned, however, that we might be starting something that could quickly get out of control if it's widely adopted (which would be a good thing). Since we don't really understand all the architectural trade-offs, we could end up with massive amounts of user data in a structure that bites us down the road.
Our biggest question is whether to have multiple sites for each use vs. a single root site from which everything else descends. Multiple sites would give us flexibility to make changes or develop new features without creating problems for all the users. However, multiple sites might be harder to back-up, search, and maintain user profiles/security. A single massive site seems to reverse the cost/benefits.
I'd appreciate any insight on the one vs. many trade-offs, or links to resources that discuss it. Links to general SharePoint "enterprise best practices" (sorry) would also be appreciated.
Thanks.
However, multiple sites might be harder
to back-up, search, and maintain user
profiles/security. A single massive
site seems to reverse the
cost/benefits.
I would consider this as incorrect. First we need to clarify when we say multiple sites, do we mean multiple site collections or multiple sites - they are two entirely different things.
Now even if they are multiple different site collections, in SQL database, they are just one database, since the database is created as web application level and not site level.
That was regarding backup.
Coming to search and user profiles, again your assumption is wrong. Search and User Profiles are Shared SErvices and they work fine as long as they reside in single Shared Services Provider. Both are farm level services.
A single massive site is (if you really mean site here not site collection) is a complete no-no and a bad design.
I would recommend having multiple site collections (something like Overall department in your company like HR, Finance , IT) and then have subistes under it. This way you have one database in SQL to manage and still you can scale by adding content database to existing web application.
Again here, I assume that you are creating your topology at company level. If this is at some lower level it needs to be refined.
Read some articles on taxonomy and site architecture on Technet before going ahead with any one.
Planning worksheets for SharePoint Server 2010
http://technet.microsoft.com/en-us/library/cc262451.aspx
Plan sites and site collections
http://technet.microsoft.com/en-us/library/cc263267.aspx
Sites and site collections overview
http://technet.microsoft.com/en-us/library/cc262410.aspx
Plan site navigation
http://technet.microsoft.com/en-us/library/cc262951.aspx
It purely depends upon your needs and requirements. even having a deferent web applications for deferent site i can provide you one citation taking backup as advantage. You might have few sites where data does not changes frequently like organizational policies, process documents etc. in this case taking regular backups/search crawling does not make sense(although you can opt for differential backup and incremental crawl but still in a week or fortnightly you have to take full backup). hence i would suggest carefully analyze your requirements and then take a decision. Microsoft has provided a good list of checklist and templates for planning purpose. few of the links are provided in madhur's reply and rest you can google upon.