{"id":776,"date":"2020-03-04T13:38:55","date_gmt":"2020-03-04T12:38:55","guid":{"rendered":"https:\/\/devpath.pro\/?p=776"},"modified":"2020-03-04T13:38:55","modified_gmt":"2020-03-04T12:38:55","slug":"book-review-domain-driven-design-quickly","status":"publish","type":"post","link":"https:\/\/fabiocicerchia.it\/programming\/book-review-domain-driven-design-quickly","title":{"rendered":"Book Review: Domain-Driven Design Quickly"},"content":{"rendered":"<p>This is my summary of the book <a href=\"https:\/\/www.infoq.com\/minibooks\/domain-driven-design-quickly\/\">Domain Driven Design Quickly<\/a>, I&#8217;ve highlighted the main concepts as a reference.<\/p>\n<figure id=\"attachment_778\" aria-describedby=\"caption-attachment-778\" style=\"width: 709px\" class=\"wp-caption aligncenter\"><a href=\"https:\/\/amzn.to\/3jzhQwh\"><img decoding=\"async\" loading=\"lazy\" class=\"wp-image-778 size-full\" src=\"https:\/\/fabiocicerchia.it\/wp-content\/uploads\/2020\/03\/model-driven-design.png\" alt=\"Model Driven Design\" width=\"709\" height=\"494\" \/><\/a><figcaption id=\"caption-attachment-778\" class=\"wp-caption-text\">Model-Driven Design &#8211; Eric Evans<\/figcaption><\/figure>\n<p><!--more--><\/p>\n<div><strong>Entities<\/strong><\/div>\n<ul>\n<li>\n<div>There is a category of objects which seem to have an identity,\u00a0which remains the same throughout the states of the software.\u00a0For these objects it is not the attributes which matter, but a\u00a0thread of continuity and identity, which spans the life of a\u00a0system and can extend beyond it. Such objects are called Entities.<\/div>\n<\/li>\n<li>\n<div>Entities are important objects of a domain model, and they should be considered from the beginning of the modelling process. It is also important to determine if an object needs to be an entity or not, which is discussed in the next pattern.<\/div>\n<\/li>\n<\/ul>\n<div><strong>Value Object<\/strong><\/div>\n<ul>\n<li>\n<div>There are cases when we need to contain some attributes of a\u00a0domain element. We are not interested in which object it is, but\u00a0what attributes it has. An object that is used to describe certain\u00a0aspects of a domain, and which does not have identity, is named\u00a0Value Object.<\/div>\n<\/li>\n<li>\n<div>Having no identity, Value Objects can be easily created and\u00a0discarded. Nobody cares about creating an identity, and the\u00a0garbage collector takes care of the object when is no longer\u00a0referenced by any other object. This simplifies the design a lot.<\/div>\n<\/li>\n<li>\n<div>It is highly recommended that value objects be immutable. They\u00a0are created with a constructor, and never modified during their\u00a0life time.<\/div>\n<\/li>\n<li>\n<div>Being immutable, and having no identity, Value\u00a0Objects can be shared.<\/div>\n<\/li>\n<li>\n<div>They also manifest integrity, i.e. data integrity.<\/div>\n<\/li>\n<li>\n<div>Value Objects should be kept thin and simple.<\/div>\n<\/li>\n<li>\n<div>Value Objects can contain other Value Objects, and they can\u00a0even contain references to Entities.<\/div>\n<\/li>\n<\/ul>\n<div><strong>Services<\/strong><\/div>\n<ul>\n<li>\n<div>When we\u00a0develop the ubiquitous language, the key concepts of the domain\u00a0are introduced in the language, and the nouns of the language are\u00a0easily mapped to objects.<\/div>\n<\/li>\n<li>\n<div>The verbs of the language, associated with their corresponding nouns become the part of the behaviour of those objects.<\/div>\n<\/li>\n<li>\n<div>But there are some actions in the domain, some verbs, which do not seem to belong to any object. They represent an important behaviour of the domain, so they cannot be neglected or simply incorporated into some of the Entities or Value Objects. Adding such behaviour to an object would spoil the object, making it stand for functionality which does not belong to it.<\/div>\n<\/li>\n<li>\n<div>Such an object does not\u00a0have an internal state, and its purpose is to simply provide\u00a0functionality for the domain.<\/div>\n<\/li>\n<li>\n<div>A Service should not replace the operation which normally\u00a0belongs on domain objects. We should not create a Service for\u00a0every operation needed.<\/div>\n<\/li>\n<li>\n<div>There are three characteristics of a Service:<\/div>\n<ol>\n<li>\n<div>The operation performed by the Service refers to a domain\u00a0concept which does not naturally belong to an Entity or Value\u00a0Object.<\/div>\n<\/li>\n<li>\n<div>The operation performed refers to other objects in the domain.<\/div>\n<\/li>\n<li>\n<div>The operation is stateless.<\/div>\n<\/li>\n<\/ol>\n<\/li>\n<\/ul>\n<div><strong>Modules<\/strong><\/div>\n<ul>\n<li>\n<div>For a large and complex application, the model tends to grow bigger and bigger. The model reaches a point where it is hard to talk about as a whole, and understanding the relationships and interactions between different parts becomes difficult. For that reason, it is necessary to organise the model into modules.<\/div>\n<\/li>\n<li>\n<div>Modules are used as a method of organising related concepts and tasks in order to reduce complexity.<\/div>\n<\/li>\n<li>\n<div>It is\u00a0widely accepted that software code should have a high level of\u00a0cohesion and a low level of coupling. While cohesion starts at\u00a0the class and method level, it can be applied at module level. It is\u00a0recommended to group highly related classes into modules to\u00a0provide maximum cohesion possible.<\/div>\n<\/li>\n<li>\n<div>Communicational cohesion is achieved\u00a0when parts of the module operate on the same data. It makes\u00a0sense to group them, because there is a strong relationship\u00a0between them.<\/div>\n<\/li>\n<li>\n<div>The functional cohesion is achieved when all\u00a0parts of the module work together to perform a well-defined\u00a0task. This is considered the best type of cohesion.<\/div>\n<\/li>\n<li>\n<div>Instead of calling three objects of\u00a0a module, it is better to access one interface, because it reduces\u00a0coupling. Low coupling reduces complexity, and increases\u00a0maintainability. It is easier to understand how a system functions\u00a0when there are few connections between modules which perform\u00a0well defined tasks, than when every module has lots of\u00a0connections to all the other modules.<\/div>\n<\/li>\n<li>\n<div>Give the Modules names that become part of the Ubiquitous\u00a0Language. Modules and their names should reflect insight into\u00a0the domain.<\/div>\n<\/li>\n<\/ul>\n<div><strong>Aggregates<\/strong><\/div>\n<ul>\n<li>\n<div>Aggregate is a domain\u00a0pattern used to define object ownership and boundaries.<\/div>\n<\/li>\n<li>\n<div>The\u00a0number of associations should be reduced as much as possible.<\/div>\n<\/li>\n<li>\n<div>An Aggregate is a group of\u00a0associated objects which are considered as one unit with regard\u00a0to data changes. The Aggregate is demarcated by a boundary\u00a0which separates the objects inside from those outside.<\/div>\n<\/li>\n<li>\n<div>Each\u00a0Aggregate has one root. The root is an Entity, and it is the only\u00a0object accessible from outside. The root can hold references to\u00a0any of the aggregate objects, and the other objects can hold\u00a0references to each other, but an outside object can hold\u00a0references only to the root object.<\/div>\n<\/li>\n<li>\n<div>If there are other Entities\u00a0inside the boundary, the identity of those entities is local,\u00a0making sense only inside the aggregate.<\/div>\n<\/li>\n<li>\n<div>If objects of an Aggregate are stored in a database, only the root\u00a0should be obtainable through queries. The other objects should be obtained through traversal associations.<\/div>\n<\/li>\n<\/ul>\n<div><strong>Factories<\/strong><\/div>\n<ul>\n<li>\n<div>In fact trying to construct a complex aggregate in its constructure is in contradiction with what often happens in the domain itself, where things are created by other things.<\/div>\n<\/li>\n<li>\n<div>When a client object wants to create another object, it calls its\u00a0constructor and possibly passes some parameters. But when the\u00a0object construction is a laborious process, creating the object\u00a0involves a lot of knowledge about the internal structure of the\u00a0object, about the relationships between the objects contained,\u00a0and the rules applied to them. This means that each client of the\u00a0object will hold specific knowledge about the object built. This\u00a0breaks encapsulation of the domain objects and of the\u00a0Aggregates.<\/div>\n<\/li>\n<li>\n<div>Creation of an object can be a major operation in itself, but\u00a0complex assembly operations do not fit the responsibility of the\u00a0created objects. Combining such responsibilities can produce\u00a0ungainly designs that are hard to understand.<\/div>\n<\/li>\n<li>\n<div>There are times when a Factory is not needed, and a simple\u00a0constructor is enough. Use a constructor when:<\/div>\n<ul>\n<li>\n<div>The construction is not complicated.<\/div>\n<\/li>\n<li>\n<div>The creation of an object does not involve the\u00a0creation of others, and all the attributes needed are\u00a0passed via the constructor.<\/div>\n<\/li>\n<li>\n<div>The client is interested in the implementation,\u00a0perhaps wants to choose the Strategy used.<\/div>\n<\/li>\n<li>\n<div>The class is the type. There is no hierarchy involved,\u00a0so no need to choose between a list of concrete\u00a0implementations.<\/div>\n<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<div><strong>Repositories<\/strong><\/div>\n<ul>\n<li>\n<div>use a Repository, the purpose of which is to\u00a0encapsulate all the logic needed to obtain object references. The\u00a0domain objects won\u2019t have to deal with the infrastructure to get\u00a0the needed references to other objects of the domain. They will\u00a0just get them from the Repository and the model is regaining its\u00a0clarity and focus.<\/div>\n<\/li>\n<li>\n<div>Repository should have a set of methods used to retrieve objects.<\/div>\n<\/li>\n<li>\n<div>We should not mix a Repository with a\u00a0Factory. The Factory should create new objects, while the\u00a0Repository should find already created objects. When a new\u00a0object is to be added to the Repository, it should be created first\u00a0using the Factory, and then it should be given to the Repository\u00a0which will store it.<\/div>\n<\/li>\n<\/ul>\n<div><strong>Refactoring<\/strong><\/div>\n<ul>\n<li>\n<div>Designing without a model can lead to software which is not true to the domain it serves, and may not have the expected behaviour.<\/div>\n<\/li>\n<li>\n<div>Modelling without feedback from the design and without developers being involved leads to a model which is not well understood by those who have to implement it.<\/div>\n<\/li>\n<li>\n<div>There are many ways to do code refactoring. There are even\u00a0refactoring patterns. Such patterns represent an automated\u00a0approach to refactoring. There are tools built on such patterns\u00a0making the developer\u2019s life much easier than it used to be.<\/div>\n<\/li>\n<li>\n<div>The\u00a0nouns are converted to classes, while the verbs become methods.\u00a0This is a simplification, and will lead to a shallow model. All\u00a0models are lacking depth in the beginning, but we should\u00a0refactor the model toward deeper and deeper insight.<\/div>\n<\/li>\n<li>\n<div>When we talk to the domain experts, we exchange a lot\u00a0of ideas and knowledge. Some of the concepts make their way\u00a0into the Ubiquitous Language, but some remain unnoticed at the\u00a0beginning.<\/div>\n<\/li>\n<li>\n<div>Implicit concepts should not stay that way. If they are domain\u00a0concepts, they should be present in the model and the design.<\/div>\n<\/li>\n<li>\n<div>Processes are usually expressed in code with procedures. We won\u2019t use a procedural approach, since we are using an object-oriented language, so we need to choose an object for the process, and add a behaviour to it. The best way to implement processes is to use a Service. If there are different ways to carry out the process, then we can encapsulate the algorithm in an object and use a Strategy.<\/div>\n<\/li>\n<li>\n<div>The last method to make concepts explicit that we are addressing\u00a0here is Specification. Simply said, a Specification is used to test\u00a0an object to see if it satisfies a certain criteria.<\/div>\n<\/li>\n<\/ul>\n<div><strong>Model Integrity<\/strong><\/div>\n<ul>\n<li>\n<div>It is so easy to start from a good model and progress toward an\u00a0inconsistent one.<\/div>\n<\/li>\n<li>\n<div>The first requirement of a model is to be\u00a0consistent, with invariable terms and no contradictions.<\/div>\n<\/li>\n<li>\n<div>The\u00a0internal consistency of a model is called unification.<\/div>\n<\/li>\n<\/ul>\n<div>\n<figure id=\"attachment_779\" aria-describedby=\"caption-attachment-779\" style=\"width: 661px\" class=\"wp-caption aligncenter\"><a href=\"https:\/\/amzn.to\/3jy82T7\"><img decoding=\"async\" loading=\"lazy\" class=\"wp-image-779 size-full\" src=\"https:\/\/fabiocicerchia.it\/wp-content\/uploads\/2020\/03\/ddd-patterns2.png\" alt=\"Bounded Context\" width=\"661\" height=\"402\" \/><\/a><figcaption id=\"caption-attachment-779\" class=\"wp-caption-text\">Domain-Driven Design &#8211; Eric Evans<\/figcaption><\/figure>\n<\/div>\n<div><strong>Bounded Context<\/strong><\/div>\n<ul>\n<li>\n<div>Each model has a context. When we deal with a single model,\u00a0the context is implicit.<\/div>\n<\/li>\n<li>\n<div>But when we work on a large\u00a0enterprise application, we need to define the context for each\u00a0model we create.<\/div>\n<\/li>\n<li>\n<div>There is no formula to divide one large model into smaller ones.<\/div>\n<\/li>\n<li>\n<div>A model should be small enough\u00a0to be assigned to one team.<\/div>\n<\/li>\n<li>\n<div>The main idea is to define the scope of a model, to draw up the\u00a0boundaries of its context, then do the most possible to keep the\u00a0model unified.<\/div>\n<\/li>\n<li>\n<div>It is hard to keep a model pure when it spans the\u00a0entire enterprise project, but it is much easier when it is limited\u00a0to a specified area.<\/div>\n<\/li>\n<li>\n<div>Explicitly define the context within which a<\/div>\n<\/li>\n<li>\n<div>model applies. Explicitly set boundaries in terms of team organisation, usage within specific parts of the application, and physical manifestations such as code bases and database schemas.<\/div>\n<\/li>\n<li>\n<div>A Bounded Context is not a Module. A Bounded Context provides the logical frame inside of which the model evolves. Modules are used to organise the elements of a model, so Bounded Context encompasses the Module.<\/div>\n<\/li>\n<li>\n<div>When using multiple models, everybody can work\u00a0freely on their own piece. We all know the limits of our model,\u00a0and stay inside the borders. We just have to make sure we keep\u00a0the model pure, consistent and unified. Each model can support\u00a0refactoring much easier, without repercussions on other models.<\/div>\n<\/li>\n<li>\n<div>There is a price to pay for having multiple models. We need to\u00a0define the borders and the relationships between different\u00a0models. This requires extra work and design effort, and there\u00a0will be perhaps some translation between different models. We\u00a0won\u2019t be able to transfer any objects between different models,\u00a0and we cannot invoke behavior freely as if there was no\u00a0boundary. But this is not a very difficult task, and the benefits\u00a0are worth taking the trouble.<\/div>\n<\/li>\n<li>\n<div>The recommended approach is to create a separate model for\u00a0each of the domains. They can both evolve freely without much concern\u00a0about each other, and even become separate applications.<\/div>\n<\/li>\n<\/ul>\n<div><strong>Continuous Integration<\/strong><\/div>\n<ul>\n<li>\n<div>If\u00a0one does not understand the relationships between objects, they\u00a0may modify the code in such a way that comes in contradiction\u00a0with the original intent. It is easy to make such a mistake when\u00a0we do not keep 100% focus on the purity of the model.<\/div>\n<\/li>\n<li>\n<div>We need a process of integration to make sure that all\u00a0the new elements which are added fit harmoniously into the rest\u00a0of the model, and are implemented correctly in code.<\/div>\n<\/li>\n<li>\n<div>Continuous Integration applies to a Bounded Context, it is not used to deal with relationships between neighbouring Contexts.<\/div>\n<\/li>\n<\/ul>\n<div><strong>Context Map<\/strong><\/div>\n<ul>\n<li>\n<div>A Context Map is a document which outlines the\u00a0different Bounded Contexts and the relationships between them.<\/div>\n<\/li>\n<li>\n<div>A Context Map can be a diagram like the one below, or it can be\u00a0any written document. The level of detail may vary.<\/div>\n<\/li>\n<li>\n<div>What it is\u00a0important is that everyone working on the project shares and\u00a0understands it.<\/div>\n<\/li>\n<li>\n<div>If the relationships between contexts are not outlined,\u00a0there is a chance they won\u2019t work when the system is integrated.<\/div>\n<\/li>\n<li>\n<div>Each Bounded Context should have a name which should be part\u00a0of the Ubiquitous Language.<\/div>\n<\/li>\n<li>\n<div>The Shared Kernel and\u00a0Customer-Supplier are patterns with a high degree of interaction\u00a0between contexts. Separate Ways is a pattern used when we\u00a0want the contexts to be highly independent and evolve\u00a0separately. There are another two patterns dealing with the\u00a0interaction between a system and a legacy system or an external\u00a0one, and they are Open Host Services and Anticorruption\u00a0Layers.<\/div>\n<\/li>\n<\/ul>\n<div><strong>Shared Kernel<\/strong><\/div>\n<ul>\n<li>\n<div>The purpose of the Shared Kernel is to reduce duplication, but\u00a0still keep two separate contexts.<\/div>\n<\/li>\n<li>\n<div>Development on a Shared\u00a0Kernel needs a lot of care. Both teams may modify the kernel\u00a0code, and they have to integrate the changes.<\/div>\n<\/li>\n<li>\n<div>If the teams use\u00a0separate copies of the kernel code, they have to merge the code\u00a0as soon as possible, at least weekly.<\/div>\n<\/li>\n<li>\n<div>A test suite should be in\u00a0place, so every change done to the kernel to be tested right away.<\/div>\n<\/li>\n<li>\n<div>Any change of the kernel should be communicated to another\u00a0team, and the teams should be informed, making them aware of\u00a0the new functionality.<\/div>\n<\/li>\n<\/ul>\n<div><strong>Customer-Supplier<\/strong><\/div>\n<ul>\n<li>\n<div>There are times when two subsystems have a special\u00a0relationship: one depends a lot on the other. The contexts in\u00a0which those two subsystems exist are different, and the\u00a0processing result of one system is fed into the other.<\/div>\n<\/li>\n<li>\n<div>There might be some overlapping, but not enough to\u00a0justify a Shared Kernel.<\/div>\n<\/li>\n<li>\n<div>A Customer-Supplier relationship is viable when both teams are\u00a0interested in the relationship. The customer is very dependent on\u00a0the supplier, while the supplier is not.<\/div>\n<\/li>\n<li>\n<div>When two development teams have a Customer-Supplier\u00a0relationship in which the supplier team has no motivation to\u00a0provide for the customer team\u2019s needs, the customer team is\u00a0helpless.\u00a0The most obvious one is to\u00a0separate from the supplier and to be completely on their own.\u00a0We will look at this later in the pattern Separate Ways.<\/div>\n<\/li>\n<li>\n<div>But because the supplier team\u00a0does not help the customer team, the latter has to take some\u00a0measures to protect itself from model changes performed by the\u00a0former team. They will have to implement a translation layer\u00a0which connects the two contexts.<\/div>\n<\/li>\n<li>\n<div>The customer context can still make use of\u00a0it, but it should protect itself by using an Anticorruption Layer\u00a0which we will discuss later.<\/div>\n<\/li>\n<li>\n<div>The customer team cannot make changes\u00a0to the kernel. They can only use it as part of their model, and\u00a0they can build on the existing code provided.<\/div>\n<\/li>\n<\/ul>\n<div><strong>Anticorruption Layer<\/strong><\/div>\n<ul>\n<li>\n<div>We can\u2019t ignore the interaction with\u00a0the external model, but we should be careful to isolate our own\u00a0model from it.<\/div>\n<\/li>\n<li>\n<div>But the\u00a0Anticorruption Layer talks to the external model using the\u00a0external language not the client one.<\/div>\n<\/li>\n<li>\n<div>This layer works as a two\u00a0way translator between two domains and languages.<\/div>\n<\/li>\n<li>\n<div>The greatest\u00a0achievement is that the client model remains pure and consistent\u00a0without being contaminated by the external one.<\/div>\n<\/li>\n<li>\n<div>A very\u00a0good solution is to see the layer as a Service from the client\u00a0model. It is very simple to use a Service because it abstracts the\u00a0other system and let us address it in our own terms. The Service\u00a0will do the needed translation, so our model remains insulated.<\/div>\n<\/li>\n<li>\n<div>The Anticorruption Layer may contain more than one Service.<\/div>\n<\/li>\n<li>\n<div>For each Service there is a corresponding Fa\u00e7ade, and for each\u00a0Fa\u00e7ade we add an Adapter. We should not use a single Adapter\u00a0for all Services, because we clutter it with mixed functionality.<\/div>\n<\/li>\n<li>\n<div>The Adapter takes care of wrapping up the behaviour of the external system. We also need object and data conversion. This is done using a translator. This can be a very simple object, with little functionality, serving the basic need of data translation.<\/div>\n<\/li>\n<\/ul>\n<div><strong>Separate Ways<\/strong><\/div>\n<ul>\n<li>\n<div>It\u2019s one thing to develop independently, to choose the\u00a0concepts and associations freely, and another thing to make sure\u00a0that your model fits into the framework of another system.<\/div>\n<\/li>\n<li>\n<div>We\u00a0may need to alter the model just to make it work with the other\u00a0subsystem. Or we may need to introduce special layers which\u00a0perform translations between the two subsystems. There are\u00a0times when we have to do that, but there are times when we can\u00a0go a different path.<\/div>\n<\/li>\n<li>\n<div>We should look at the requirements and see if they can be divided in two or more sets which do not have much in common. If that can be done, then we can create separate Bounded Contexts and do the modelling independently.<\/div>\n<\/li>\n<li>\n<div>Before going on Separate Ways we need to make sure that we\u00a0won\u2019t be coming back to an integrated system. Models\u00a0developed independently are very difficult to integrate. They have so little in common that it is just not worth doing it.<\/div>\n<\/li>\n<\/ul>\n<div><strong>Open Host Service<\/strong><\/div>\n<ul>\n<li>\n<div>When we try to integrate two subsystems, we usually create a\u00a0translation layer between them.<\/div>\n<\/li>\n<li>\n<div>If the external subsystem turns\u00a0out to be used not by one client subsystem, but by several ones,\u00a0we need to create translation layers for all of them. All those\u00a0layers will repeat the same translation task, and will contain\u00a0similar code.<\/div>\n<\/li>\n<li>\n<div>The solution is to see the external subsystem as a provider of\u00a0services. If we can wrap a set of Services around it, then all the\u00a0other subsystems will access these Services, and we won\u2019t need\u00a0any translation layer.<\/div>\n<\/li>\n<li>\n<div>The difficulty is that each subsystem may\u00a0need to interact in a specific way with the external subsystem,\u00a0and to create a coherent set of Services may be problematic.\u00a0Then, use a one-off translator to augment\u00a0the protocol for that special case so that the shared protocol can\u00a0stay simple and coherent.<\/div>\n<\/li>\n<\/ul>\n<div><strong>Distillation<\/strong><\/div>\n<ul>\n<li>\n<div>Distillation is the process of separating the substances\u00a0composing a mixture.<\/div>\n<\/li>\n<li>\n<div>The idea is to define a Core Domain which\u00a0represents the essence of the domain.<\/div>\n<\/li>\n<li>\n<div>The byproducts of the\u00a0distillation process will be Generic Subdomains which will\u00a0comprise the other parts of the domain.<\/div>\n<\/li>\n<li>\n<div>The Core Domain of a system depends on how we look at the\u00a0system.<\/div>\n<\/li>\n<li>\n<div>Boil the model down. Find the Core Domain and provide a means of easily distinguishing it from the mass of supporting model and code. Emphasize the most valuable and specialised concepts. Make the Core small.<\/div>\n<\/li>\n<li>\n<div>Spend the effort in the Core to find a deep model and develop a supple design\u2014sufficient to fulfil the vision of the system.<\/div>\n<\/li>\n<li>\n<div>Apply your top talent to the Core Domain, and recruit\u00a0accordingly.<\/div>\n<\/li>\n<li>\n<div>There is\u00a0a process of refinement and successive refactorings are\u00a0necessary before the Core emerges more clearly.<\/div>\n<\/li>\n<li>\n<div>There are different ways to implement a Generic Subdomain:<\/div>\n<ul>\n<li>\n<div>Off-the-shelf Solution.<\/div>\n<\/li>\n<li>\n<div>Outsourcing.<\/div>\n<\/li>\n<li>\n<div>Existing Model.<\/div>\n<\/li>\n<li>\n<div>In-House Implementation.<\/div>\n<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"<p>This is my summary of the book Domain Driven Design Quickly, I&#8217;ve highlighted the main concepts as a reference.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"advgb_blocks_editor_width":"","advgb_blocks_columns_visual_guide":"","footnotes":""},"categories":[86,37],"tags":[110,111,112],"aioseo_notices":[],"author_meta":{"display_name":"fabio","author_link":"https:\/\/fabiocicerchia.it\/author\/fabio"},"featured_img":null,"coauthors":[],"tax_additional":{"categories":{"linked":["<a href=\"https:\/\/fabiocicerchia.it\/category\/methodologies\" class=\"advgb-post-tax-term\">Methodologies<\/a>","<a href=\"https:\/\/fabiocicerchia.it\/category\/programming\" class=\"advgb-post-tax-term\">Programming<\/a>"],"unlinked":["<span class=\"advgb-post-tax-term\">Methodologies<\/span>","<span class=\"advgb-post-tax-term\">Programming<\/span>"]},"tags":{"linked":["<a href=\"https:\/\/fabiocicerchia.it\/category\/programming\" class=\"advgb-post-tax-term\">book<\/a>","<a href=\"https:\/\/fabiocicerchia.it\/category\/programming\" class=\"advgb-post-tax-term\">ddd<\/a>","<a href=\"https:\/\/fabiocicerchia.it\/category\/programming\" class=\"advgb-post-tax-term\">summary<\/a>"],"unlinked":["<span class=\"advgb-post-tax-term\">book<\/span>","<span class=\"advgb-post-tax-term\">ddd<\/span>","<span class=\"advgb-post-tax-term\">summary<\/span>"]}},"comment_count":"0","relative_dates":{"created":"Posted 4 years ago","modified":"Updated 4 years ago"},"absolute_dates":{"created":"Posted on March 4, 2020","modified":"Updated on March 4, 2020"},"absolute_dates_time":{"created":"Posted on March 4, 2020 1:38 pm","modified":"Updated on March 4, 2020 1:38 pm"},"featured_img_caption":"","series_order":"","_links":{"self":[{"href":"https:\/\/fabiocicerchia.it\/wp-json\/wp\/v2\/posts\/776"}],"collection":[{"href":"https:\/\/fabiocicerchia.it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/fabiocicerchia.it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/fabiocicerchia.it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/fabiocicerchia.it\/wp-json\/wp\/v2\/comments?post=776"}],"version-history":[{"count":0,"href":"https:\/\/fabiocicerchia.it\/wp-json\/wp\/v2\/posts\/776\/revisions"}],"wp:attachment":[{"href":"https:\/\/fabiocicerchia.it\/wp-json\/wp\/v2\/media?parent=776"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/fabiocicerchia.it\/wp-json\/wp\/v2\/categories?post=776"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/fabiocicerchia.it\/wp-json\/wp\/v2\/tags?post=776"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}